fix(core): retry snapshot capture when concurrent Git writes collide on Windows - #56190

Summary

Snapshot > captures concurrently from independent processes flakes on Windows CI (3 of the last 15 failed test.yml runs on dev, e.g. 38931653291). The diagnostics added in #56181 surfaced the cause:

Git.OperationError operation: "write_tree"
error: unable to write file ...\snapshot\...\objects/d2/475eb0...: Permission denied
fatal: git-write-tree: error building trees

Independent processes capturing into the same snapshot store often write identical loose objects. On Windows, when two Git processes finalize the same object at the same moment, the loser gets a sharing violation instead of "already exists" and exits non-zero. capture() is best-effort, so the snapshot is silently lost.

Change

Only on Windows, the two commands that write objects, update-index --add (blobs) and write-tree (trees), are retried up to 2 times (3 attempts total, 50 ms apart) when Git exits non-zero. Objects are content-addressed, so a retry finds the other process's copy in place. Only the failing command reruns; there is no new worktree scan.

Unchanged behavior:

• Other platforms fail on the first attempt as before.
• A failure to start Git is never retried.
• Other Git commands (listing, removals, index probing) are not retried, and the unreadable-index rebuild path in captureTree is untouched.

Trade-off: on Windows, a persistent failure in one of these two commands, such as an unreadable worktree file during update-index, costs two extra runs of that command (~100 ms) before surfacing. Telling it apart from the race would mean matching Git's possibly localized stderr, which this code avoids elsewhere.

Testing

• bun typecheck in packages/core
• bun test test/snapshot.test.ts test/git.test.ts --rerun-each 3

The race did not reproduce locally (30/30 passes without the fix), so Windows CI is the real signal.