perf(fsmonitor): resolve all daemons in one lsof spawn

[max-sixty]

Why

wt remove's end-of-command fsmonitor sweep forked one lsof per machine-wide git fsmonitor--daemon — and with core.fsmonitor enabled globally, a machine accumulates one daemon per repo ever touched (100+ is routine). So every wt remove paid ~100 process spawns. The cost is superlinear under load, not linear: a fork storm makes macOS Gatekeeper/XProtect assess each new image under contention, inflating per-spawn cost for everything else on the box, sweeps included. The ~50ms each figure in the old docstring was measured under that load and read as a fixed per-call cost — so the sweep looked merely slow rather than self-amplifying. Two concurrent test suites driving hundreds of wt remove calls pinned all 18 cores (load average 142) with nothing hot in htop.

This was diagnosed and measured before (#2814 added the sweep; #3401 wrote the cost into the docstring and explicitly changed no behavior) but never fixed.

The fix

Resolve every daemon in a single lsof -a -p <pid1,pid2,…> -U -F pn call and split its output on the p<pid> record boundary, handing each PID exactly the output the per-PID call produced — so classification and the whole data-safety contract in the module docs are unchanged. Verified end-to-end against a live 108-daemon machine with a PATH shim counting invocations: 108 spawns → 1.

Two details the batched path must preserve, each covered by a new test:

• Don't gate on lsof's exit status. It exits non-zero when any requested PID vanished mid-scan, while still printing full records for every survivor. Gating would drop the whole sweep whenever one daemon happened to exit — the common case on a busy machine.
• A PID with no record is dropped, never synthesized as a socket-less entry. A socket-less entry reads as orphan class 1 and gets SIGTERM/SIGKILL — on a possibly-recycled PID.

Also here

• Test consolidation. Three integration fixtures built their branch set by spawning git per loop iteration. A new TestRepo::create_branches creates them in one git update-ref --stdin. The over-threshold completion test drops 10.5s → 1.4s (~230 git spawns → 5); switch_picker and statusline branch loops get the same treatment. mock-stub gains an opt-in MOCK_CALL_LOG_DIR call log so a test can assert spawn count, not just response — deliberately outside the repo under test, since a log written inside the tree would dirty it mid-wt merge.

• Docs. Dropped the "disable core.fsmonitor globally" workaround from the troubleshooting docs (canonical skills/, mirror regenerated). It stays enabled by choice, and the daemons were never the actual fseventsd CPU driver.

• CI hardening. pre-commit.ci's typos hook maps the token pn→on and had auto-rewritten lsof -F pn to the broken lsof -F on (offset+name — no p<pid> records, so the parser reaps nothing). Pinned pn in .typos.toml next to the existing PN-from-PNGs entry that documents the same mapping, and added a test covering the empty-PID-set early return (flagged by codecov/patch).

Testing

New unit tests cover daemons_from_batched_lsof against real captured lsof -F pn output, a vanished-PID gap, and empty output; the rewritten integration test asserts exactly one lsof spawn with a comma-joined PID list. Full integration suite green (1960 passed), clippy and fmt clean.

This was written by Claude Code on behalf of max

[worktrunk-bot]

codecov/patch is red on this PR — 97.36% of the diff hit vs a 97.83% target. The two uncovered added lines are both return Vec::new() early-returns in the new enumerate_daemons (src/git/fsmonitor.rs):

• the empty-PIDs guard — if pids.is_empty(), reached when pgrep exits 0 but yields no parseable PID;
• the lsof-spawn-failure backstop — the let Ok(out) = … else arm.

Only one of the two needs covering to clear the gate (one more hit takes the 76-line diff to ~98.7%, above target). The empty-PIDs guard is the clean one to test: mock pgrep to emit non-numeric output (exit 0) so the parse::<u32>() filter drops it to an empty set — the same mock shape as test_remove_resolves_all_fsmonitor_daemons_in_one_lsof. The spawn-failure arm is a load-bearing backstop that's awkward to trigger deterministically, so I'd leave it uncovered.

Happy to push that test if you'd like. Otherwise, per the repo's codecov policy these defensive returns need your explicit sign-off to merge over the gate.

Dismissing the earlier approval — it landed ~6 minutes before codecov's verdict was in — until the gap is closed or you approve merging over it. The incremental typos pin (pn = "pn") restoring the intended -F pn field spec looks correct.

codecov/patch failing (97.36% vs 97.83% target) — this approval landed before codecov's verdict was in. Dismissing until the empty-PIDs guard in enumerate_daemons is covered or the merge is explicitly signed off.