Syncing synthetic global project metadata overwrites machine-specific worktree state

[logser13]

Summary

opencode-github-sync 3.0.1 exports the OpenCode synthetic project.id = "global" row into every session shard that references it.

That global project row contains machine-specific metadata such as worktree, vcs, and time_updated. When session shards move between machines, importing that row can overwrite the receiving machine's own global project metadata.

This causes cross-machine churn and can replace paths or project routing metadata with values from another computer.

Environment

• opencode-github-sync: 3.0.1
• OpenCode Desktop / CLI: 1.18.30
• Two Windows 11 machines
• Same session repository shared between machines

Reproduction

1. Use two OpenCode machines with different local project/worktree state.
2. Export sessions whose project_id is global.
3. Inspect the generated session shards: each contains a project object for id = global.
4. Pull/import those shards on the other machine.
   Observed in testing: the two machines had different values for the same synthetic global project row, including different worktree / vcs metadata. Re-exporting from one machine could therefore make the other machine's shards dirty again or replace local global-project metadata during import.

Expected result

Machine-local synthetic global project metadata should not be transported as if it were a normal portable project record.

Session data should remain portable without mutating the receiving machine's global project row.

Tested workaround

Skipping the project record when the session references the synthetic global project avoids the cross-machine overwrite:

const projectId = sessionRow.project_id;
if (projectId && projectId !== "global") {
  shard.project = readRows(
    db,
    "SELECT * FROM project WHERE id = ?",
    [projectId],
  )[0];
}

With that exclusion plus deterministic shard metadata, repeated syncs between the two machines remain clean when the sessions themselves have not changed.

Suggested regression test

1. Create two local DB fixtures where project.id = global has different machine-specific metadata.
2. Export a global session from machine A.
3. Import it into machine B.
4. Assert machine B's existing project.id = global row is unchanged.
5. Assert the session/messages/parts are still imported successfully.

Related: #2 covers a separate data-loss problem caused by INSERT OR REPLACE during import.