fix(opencode): use extendEnv: false in snapshot git helper to prevent index corruption from hooks

[MAnders333]

Issue for this PR

Closes #22477

Type of change

• Bug fix

What does this PR do?

When opencode runs inside a pre-commit hook, git sets GIT_INDEX_FILE in the hook's environment pointing at the working repo's index. The snapshot service's git subprocess helper used extendEnv: true, which inherited this variable. Because GIT_INDEX_FILE takes higher priority than the index path implied by --git-dir, all snapshot git commands (add, write-tree) wrote into the working repo's index rather than the shadow repo's index. Blobs went to the shadow's object store but index entries ended up in the working repo, leaving it with references to objects that don't exist locally — breaking the commit.

The fix switches to extendEnv: false and passes only PATH and HOME explicitly. That's all a local git plumbing operation needs. This mirrors what git itself does via sanitize_repo_env() when crossing repo boundaries. The same fix is applied to the cat-file --batch call in load() which bypassed the shared git() helper.

How did you verify your code works?

Reproduced the corruption manually: set up a pre-commit hook that runs opencode run --agent reviewer, staged specific files, ran git commit, and confirmed the index was corrupted afterward (previously unstaged files staged, error: invalid object on commit). Traced the root cause through git source (commit.c:run_commit_hook sets GIT_INDEX_FILE; repository.c:expand_base_dir gives it priority; cross-spawn-spawner.ts:env() merges it into subprocess env via extendEnv: true). After the fix, the working repo index is unchanged after the opencode session.

Checklist

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