[worktrunk-bot]

Problem

Concurrent wt step prune removals race at the git level on the worktree registry (issue #3661). git worktree remove enumerates every entry under .git/worktrees/ and reads each sibling's commondir while resolving its target, so when two removals overlap, one can read a sibling's commondir in the window after a concurrent worker has begun tearing that sibling's admin dir down — a TOCTOU between the enumerator's readdir and its open. The same window fails a branch delete's list_worktrees checkout probe with Invalid path .../.git/worktrees/<id>. Both surfaced in CI: the commondir failure in the flaky coverage run, the Invalid path failure in the nightly benchmarks run.

Per the maintainer's call on #3661: serialize now, move things off the serial path later.

Solution

A second lock, RemovalContext::registry_lock, serializes the registry-mutating removals:

• A removal that unregisters an entry (git worktree remove — every Worktree plan, a BranchOnly plan carrying a stale prune_entry, and StaleDetached) holds the write side.
• A removal that only reads the registry (a plain branch deletion's list_worktrees checkout probe) holds the read side, so those still run concurrently.

Kept distinct from the existing check_lock on purpose: the integration-check fan-out never enumerates the registry live (it plans off the cached list_worktrees snapshot), so it keeps overlapping removals rather than serializing behind them — which preserves the .git/config-race canary's premise. Removals acquire check_lock first, then registry_lock, in a fixed order, so the two never deadlock.

This gives up the parallel prune of many stale entries (a cheap, rare operation) in exchange for correctness, and avoids parsing git's raw fatal: strings — the tradeoff the issue laid out for option (1).

Testing

test_prune_metadata_removals_run_concurrently is reworked into test_prune_metadata_removals_serialize: the shim now probes for teardown overlap with an atomic mkdir lock and asserts none occurs. Verified it's a genuine regression detector — downgrading the write guard to a read guard makes it fail with two git worktree remove teardowns overlapped. The concurrency-preserving tests still pass unchanged: test_prune_removals_run_concurrently (branch-only removals stay parallel) and test_prune_fallback_config_race_canary (removals still overlap the scan). Full step_prune module green (51 tests); clippy + fmt clean.

Closes #3661

[worktrunk-bot]

Independent review of the concurrency change. No defect found — the two-lock design holds up under tracing — but flagging for maintainer sign-off per the repo's data-safety policy, since this reworks the wt step prune worktree-removal (git worktree remove) scheduling path (src/commands/step/prune.rs, src/git/repository/worktrees.rs).

What I verified:

• No deadlock. Every removal acquires check_lock before registry_lock in a fixed order (try_remove's StaleDetached branch and its main branch both do so), so the two locks can't deadlock.
• Every live registry enumeration is covered. The only operations that walk .git/worktrees/ live during the fan-out are the git worktree remove teardowns (prune_worktree_entry / remove_worktree) and fresh_branch_checkout's list_worktrees probe (the fresh git worktree list --porcelain in delete_branch_if_safe). Teardowns hold registry_lock write; the plain branch-delete probe holds read; both run synchronously inside the guard scope (prune_worktree_entry and remove_worktree are blocking run_commands, and the fast path's stage_worktree_removal prunes inline before backgrounding only the rm -rf). The integration check and ensure_clean's git status don't enumerate siblings, so leaving the check fan-out on the read side without serializing behind registry_lock is sound.
• The reworked test is a genuine regressor. test_prune_metadata_removals_serialize's mkdir-based overlap probe fires only if two teardown subprocesses run concurrently, which the write guard prevents; downgrading it to a read guard would drop the overlap- sentinel the test asserts absent.

The one load-bearing assumption worth a second pair of eyes: that the integration-check fan-out never enumerates the registry live (the premise for keeping it overlapping removals rather than serializing behind registry_lock, and for preserving the .git/config-race canary). It held everywhere I traced, but it's the assumption that would make the fix incomplete if wrong.

Not approving (self-authored, and data-loss surface).