fix(snapshot): reuse source git objects to avoid re-hashing huge repos

[dmtrKovalenko]

Issue for this PR

Closes#31797

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Opening a session in a huge repo (chromium, ~500k files) hangs because the first Snapshot.track does git add --all into a brand-new, empty snapshot repo, so git re-hashes the entire working tree from scratch. That takes minutes, so the turn never finishes.

The source repo already has every file hashed in its own object DB. So when we create the snapshot repo, this PR seeds it from the source repo:

• point objects/info/alternates at the source repo's object dir (so git reuses blobs it already has)
• copy the source repo's index (so add becomes a stat-only diff instead of hashing everything)

It's all best-effort and guarded: non-git projects are skipped, and a missing/incompatible source index just falls back to the old full add. The resulting tree hash is identical to the old path, so snapshot/diff/revert behave exactly the same.

How did you verify your code works?

• On a full chromium checkout (~500k files, 69G): before this change git add --all did not finish within 90s and session.prompt hung (process had to be killed). After, the first snapshot completes in ~5s and opencode run exits cleanly.
• Confirmed the snapshot produces the same valid tree hash as before (all 500,259 entries resolve).
• bun typecheck passes.
• bun test test/snapshot/snapshot.test.ts passes (52 pass, 0 fail).

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[dmtrKovalenko]

Heads up: test, typecheck, and nix-eval are sitting in action_required (first-time fork contributor approval gate). Everything else (pr-standards, compliance, duplicates) is green. Locally bun typecheck passes and the snapshot/session/git suites pass (61 pass, 0 fail). Ready to run once a maintainer approves the workflows.

[Hyyy6]

Looks like this fix does not cover worktrees scenario. I have a large project with a bunch of worktrees, and starting opencode from any worktree hangs the terminal with no response
After doing researching and checking logs, the issue was due to git add --all. Then I discovered this PR that addresses it, the fix is live, and my version is up to date.

This is models output after describing the issue and pointing to this PR:

The fix is a one-line change at line 229 of packages/opencode/src/snapshot/index.ts:
- Current (broken for worktrees): const sourceIndex = path.join(source, "index") — source comes from --git-common-dir, so it always points to the main repo's .git/index
- Fixed: Run git rev-parse --git-path index with cwd: state.worktree, which resolves to the correct worktree-specific index path (e.g. .git/worktrees/<name>/index), falling back to the old behavior if it fails

Looking at PR changes the proposed fix makes sense.
And indeed if opencode is started from main repo there is no problem.
Please let me know if this rather be submitted as another ticket.