Sync local git remains in resolveThreadGit / defaultBranch on the PR read paths #228

Split out of #124, which converted the dominant offenders. This is the small honest remainder.

electron/worktrees.js no longer runs any synchronous gh (sync ghTry was deleted). But two helpers still use the synchronous execCommand git wrapper, and they sit on paths that are read-only and user-facing:

• resolveThreadGit (~line 1520) — used by prStatus, createPr, mergePr
• defaultBranch (~line 187) — used by listPrs, createPr, and the worktree flows

So listPrs and prStatus now have async gh but still make ~2 synchronous local git calls each (remote get-url origin, branch --show-current).

Why this was left

Scale. Measured in #124, local git under concurrency is ~30-50ms p99; the gh calls that were fixed were bounded at 30_000ms and are network-bound. Two local git calls on a PR view is real but roughly three orders of magnitude below what was actually causing the beachball, and converting resolveThreadGit cascades into the worktree write flows (setupWorktree, mergeWorktree, push, commit, revertFile, cleanupWorktree) which are all still deliberately sync.

Deliberately still sync, and fine

The worktree write paths — setupWorktree, mergeInto / mergeWorktree, push, commit, revertFile, cleanupWorktree, unmergedFiles, maybeRenameWorktreeBranch. They fire once per deliberate click and are bounded at 15s by #88. Marked in-file with a ponytail: comment at the sync gitOut helper so the remainder is documented rather than rediscovered.

Worth doing when

If event-loop lag instrumentation (CODER_LOOP_LAG=1, added in #124) shows the PR/Git tab still contributing measurable p99 under concurrent runs. Measure before converting — that is what #124 established as the working method, and it is what stopped the store-stringify work from being a guess.

Async helpers already exist in the file (gitOutAsync, gitOutForDiffAsync, gitTryAsync, gitExecThrowAsync), so this is routing, not new machinery.