fix: exempt the foreground thread from the command semaphore

[max-sixty]

Accepting a row in the wt switch picker could stall for ~10s on a large repo — and indefinitely under sustained background traffic — before the switch began. Every Cmd::run acquires the global 32-permit command semaphore, so the accept path's first command queued behind the picker's per-row preview diffs, which on a 38-worktree rust-lang/rust fixture each held a permit for ~14s (trace: Enter at t=4.3s, first switch command spawned at t=14.3s, all of it inside semaphore().acquire()). Since permits go to an arbitrary waiter (Condvar::notify_one), the foreground can also lose every race while background tasks keep replenishing the queue.

The foreground thread — the one that enters main() — now bypasses the semaphore in run and pipe_into. It executes commands one at a time, so it can't contribute to the fan-out the semaphore exists to bound, and it's what the user is waiting on. stream/delayed_stream already followed this rule; background pool tasks keep the full 32-permit cap. The cap was already approximate (rayon work-stealing can run a capped closure on the calling thread), so no permits are reserved.

Verified with a PTY driver against a repo whose git shim sleeps 15s on diff, with WORKTRUNK_MAX_CONCURRENT_COMMANDS=2: accept-to-exit was >100s before (killed) and 0.08s after; a control run of the unfixed binary with an unsaturated cap also exits in 0.08s, isolating the semaphore as the cause. A unit test covers the exemption (initializing thread exempt, spawned threads capped).

This was written by Claude Code on behalf of max

[worktrunk-bot]

Looks correct and cleanly scoped — the foreground exemption is what the user waits on, it can't fan out past one command from a single thread, and the rayon work-stealing overage is acknowledged. init_startup capture ordering (first line of main, before the rayon pool spawns) is right, the rename is complete, and the Option<SemaphoreGuard> RAII holds/drops correctly in both branches. The unit test pins both directions of the exemption.

One small doc drift, just outside the diff: pipe_into's doc still says "The pipeline consumes one semaphore permit even though it runs two processes concurrently" — now that the foreground thread bypasses the guard, that's only true on background threads (foreground consumes zero). Happy to push a one-line tweak to that comment if you'd like; not blocking.