fix(prune): serialize integration checks against branch -D (Windows .git/config race)

[max-sixty]

Summary

On Windows, wt step prune intermittently panicked prune should succeed with unable to access '.git/config': Permission denied. prune runs parallel integration_reason branch-integration checks (each spawns git subprocesses that read .git/config) on a background thread while the main loop performs inline removals — and the fast-path removal synchronously runs git branch -D, which rewrites .git/config (it removes the branch's [branch "<name>"] section) via git's lockfile + atomic-rename. On Windows the rename briefly holds .git/config with delete access; a concurrent reader's fopen(...,"r") does not pass FILE_SHARE_DELETE and is not retried, so it fails. POSIX open()/rename() semantics never exhibit this — Linux/macOS CI is green.

Approach (the "B-prime" option)

A prune-local Arc<RwLock<()>>: each integration_reason call is wrapped in a read guard (scoped to drop before the channel send); try_remove takes the write guard over its body. The write guard blocks until every in-flight reader has dropped and blocks new ones until the removal completes, so no integration-check git process is alive while the synchronous git branch -D rewrites .git/config. The parallel checks themselves are not serialized — only a reader-vs-removal overlap is excluded — so prune's streaming/interleaved output (the property that fixed the historical start-silence) is unchanged. The lock is confined to prune.rs; the read path is a single guarded scope with no changes to integration_reason, Cmd, or handlers.rs.

Alternatives considered and rejected: full serialization (reintroduces start-silence); git update-ref -d + deferred config-section purge (a Ctrl-C between ref delete and purge leaves a silent ghost-upstream that can corrupt prune's own integration decisions — a data-safety regression); a global git mutex (invasive, kills the parallelism). Poisoning is recovered via unwrap_or_else(|e| e.into_inner()) rather than .expect() — the lock guards (), so a poisoned lock is meaningless and panicking would only cascade an unrelated panic across every later removal.

Known residual gap (deliberate, documented — not closed here)

B-prime closes the race on the instant-rename fast path, which is the path the observed CI failure took (synchronous git branch -D under the guard). On the cross-filesystem / .gitmodules / Windows-file-lock fallback, git branch -D must be deferred into a detached git worktree remove && git branch -D (the worktree still references the branch until it is removed, so an in-process branch -D would fail) — that deferred write runs after the guard drops and is not covered. The fallback is rare for prune targets (integrated worktrees the user is done with; the lock-prone current worktree is deferred last, after the check thread has drained), so the residual exposure is small but non-zero. The check_lock rationale comment documents this precisely rather than overclaiming an unconditional guarantee.

test_prune_fallback_config_race_canary is the empirical probe for whether that residual gap matters: it forces the fallback for one non-current integrated worktree (pre-blocking its staged path) while several other integrated worktrees keep the parallel integration fan-out running, so the deferred config-rewriting branch -D overlaps live .git/config readers. On POSIX it is a deterministic fallback-path smoke test (a concurrent read and rename never collide). On Windows it is a canary: a flake here during normal CI runs is empirical proof the fallback path needs closing (which would require synchronous/foreground fallback removal — a real perf regression, hence deferred to evidence rather than decided on speculation). The canary asserts only the immediate race signal (prune exit + absence of the .git/config error); removal-completion polling was intentionally dropped after it proved load-sensitive (a 60s wait_for timeout under heavy concurrent load) and carries no canary value.

Testing

pre-commit run --all-files clean; full suite green (3737 passed, 0 skipped); prune suite 36 passed, 0 failed. The fix's correctness is established by macOS reasoning + the green macOS suite; the actual Windows-only behavior can only be confirmed by test (windows) here (the originally-flaking test_prune_locally_merged_when_upstream_diverged going/staying green) and by the canary's flake rate over subsequent Windows runs.

Ref #2801