v0.9.14: Move git subprocess calls out of the fleet subagent write lock

From `codewhale-ops/PERF-OPPORTUNITIES-20260915.md` §2 R2 **[V code / S lock path]**.

`crates/tui/src/tools/subagent/mod.rs:1207–1245` `claimed_diff_taint` spawns `git status --porcelain` and `git log --name-only` — 10–100ms each on large repos — from `complete_worker_from_result` (`mod.rs:5555`), which the scan places under `manager.write().await` (`mod.rs:10378`, `coord.rs:238/395/419`). Every status/wait/mailbox operation serializes behind two synchronous subprocess spawns.

**Fix:** move the taint computation into `spawn_blocking` and apply it to the worker record via a follow-up lock acquisition, or compute lazily on first read. The `GIT_OPTIONAL_LOCKS=0` hygiene is already right — only the lock placement is wrong.

General rule this violates (already followed elsewhere in the repo): `spawn_blocking` for subprocess + fs — and never while holding a lock.

Start in crates/tui/src/tools/subagent/mod.rs at claimed_diff_taint (1207–1245) and complete_worker_from_result (5555), then trace the manager.write().await sites at mod.rs:10378 and coord.rs:238/395/419. Verify the existing spawn_blocking pattern elsewhere in the repository. Done means git status and git log no longer run while the write lock is held, while taint computation still updates or is available on the worker record.

Written by the indexing model from the issue text.