fix(vscode): honor configured Git executable for worktrees

[marius-kilocode]

What Problem This Solves

Agent Manager can report that Git is missing on Windows even when Git for Windows works in the built-in VS Code Git integration. The confirmed bug is that Agent Manager ignores the executable selected by VS Code and depends on the extension-host PATH instead.

The old Windows resolver always returned the literal command git. Worktree availability checks, worktree Git clients, and state-transfer commands also invoked bare git. Setting git.path therefore did not help those operations. A working integrated terminal was not proof that these extension-host subprocesses could find Git, because the terminal can have a different environment.

Fixes #13452.

Why This Change Was Made

Use the executable already resolved by the built-in VS Code Git API, including its support for git.path, rather than adding a second Kilo setting or guessing Git installation directories. Pass that same trusted executable through worktree creation and discovery, Git LFS checks, shared Git operations, project discovery, and Continue in Worktree state capture/apply. This also supports normal installation paths containing spaces, such as C:/Program Files/Git/cmd/git.exe.

Waiting for the Git API must not block Kilo startup indefinitely. Preferred Windows Git resolution now has a three-second timeout. If the Git extension is unavailable, rejects, or does not finish in time, Kilo logs the failure and falls back to normal PATH lookup. The timer is cleared after resolution, concurrent callers share one result, and a late rejection cannot replace the fallback or become an unhandled rejection.

The selected executable is not written to the global PATH. The existing macOS and Linux resolution behavior is preserved. Git availability is cached per worktree manager rather than across managers with potentially different executables.

User Impact

Windows users can create worktrees and continue sessions with staged and unstaged edits when VS Code has found a Git executable that the extension-host PATH cannot resolve. No new setting is required.

A slow Git extension can delay preferred executable lookup by at most three seconds, instead of indefinitely. The selected executable or fallback is cached for the extension session, so changing the Git installation or configuration requires a VS Code reload. PATH fallback preserves startup, but it cannot make Git available if neither VS Code resolution nor PATH lookup succeeds.

No workflow changes or additional recurring CI jobs remain in this PR. The regression tests run in the existing extension unit suite.

Evidence

Reproducing the Git lookup bug

1. Create a real temporary Git repository with an initial commit and resolve its installed Git executable to an absolute path.
2. Run the actual WorktreeManager and GitOps implementation in a separate Bun process. Replace PATH with a directory containing a failing Git shim, while retaining the explicit executable.
3. Attempt worktree creation. Before the fix, the Windows resolver returned git instead of the configured executable and the worktree preflight failed at git --version.
4. With the fix, create a real worktree, check its branch and working-tree changes, then capture and apply staged and unstaged edits using the same explicit executable. The regression also exercises executable paths containing spaces.

One-time native Windows validation passed for executable resolution, real worktree creation, Git operations, and project discovery: Windows 2025 run. The temporary Windows job was removed after that validation to avoid its recurring setup cost.

Reproducing the startup risk

Give the real Windows resolver a preferred Git lookup Promise that never settles. Before the guard, both hanging-lookup tests exceeded their one-second test deadlines. After the guard, the tests resolve to git, share the cached fallback, and safely handle a rejection that arrives after the timeout. Tests inject a 10 ms timeout so they do not add a three-second wait to CI.

A separate local process using the production default returned the PATH fallback after 3,001 ms. This used the real resolver with a simulated hanging Git API, not a native Windows UI hang. The native Windows run above predates this timeout-only follow-up.

Validation

• Full extension unit suite: 4,212 passed, 0 failed.
• Focused resolver suite: 16 passed, including hanging lookup, late rejection, successful lookup, caching, and existing macOS behavior.
• The actual resolver was also bundled and executed in Node with --unhandled-rejections=strict. Rejecting the preferred lookup after the timeout exited successfully and kept the PATH fallback; Promise.race already attaches a rejection handler to each input.
• All applicable CI and code-review checks passed for dbb019c0aa. The late-rejection review warning was verified as a false positive and resolved without a reply or unnecessary code changes.
• Extension build, lint, host/webview typechecks, formatting, unused-export checks, and merge-marker checks passed.
• Isolated VS Code smoke test on macOS: Agent Manager created a worktree in a disposable repository; git worktree list confirmed its branch. The isolated instance and fixture were cleaned up.

Manual Test

On Windows, configure VS Code to use an installed git.exe that is not available through the extension-host PATH. Reload VS Code, create an Agent Manager worktree, then use Continue in Worktree with staged and unstaged edits. Both the new worktree and the transferred edits should be present.

Remaining uncertainty

The original reporter has not yet confirmed the patched build on their machine. Their follow-up says terminal Git works and restarts did not help. The existing UI classifier maps any ENOENT to “Git not found,” including unrelated missing-path failures; this PR does not change that classifier. The reproduced executable-selection bug is fixed, but confirming the exact cause of the original machine-specific report still requires the patched-build result or its underlying error.

[WebReflection]

Looks good, happy to learn how we test on Windows targets locally, if that's something possible already, 'cause I haven't done that yet. We can discuss this async.