fix(tests): pin the spawned wt binary against concurrent cargo uplifts

[max-sixty]

Two test-suite flakes fixed at the root, both dependencies on machine load and concurrent builds.

Concurrent-cargo spawn NotFound. Cargo uplifts target/debug/wt by removing the path and recreating it, so a second cargo against the same target directory leaves the binary every test spawns absent for a fraction of a millisecond per rebuild — the one-off NotFound spawn failures that pass on re-run. wt_bin() now returns a hardlink pinned under target/debug/wt-test-bin/<mtime>-<len>/: the uplift unlinks only the uplifted name, so the pin keeps serving the observed binary through any number of concurrent rebuilds, at no disk cost beyond the deps/ artifact whose inode it shares. test_wt_spawns_are_pinned keeps every spawn routed through it. Reproduced by re-creating the uplift every 200 ms alongside a full cargo nextest run: 302 of 4583 tests failed before this change (147 as direct NotFound spawn panics, five of them byte-identical to the original shell-wrapper report), 4585 of 4585 after — with an unrelated external cargo also rebuilding wt mid-validation, absorbed the same way.

--reap probe races. test_remove_reap_kills_process predicted the reap guard's verdict with its own lsof/ps snapshot, and under load either probe's spawn can stall past the 5 s bound, whose fail-safe empty result flips the outcome — a prediction wt then contradicts, or wt reporting "No processes to reap" for a live child. The prediction now reads the session's controlling terminal directly (/dev/tty opens iff the session has one — the property the child inherits at spawn), the probe timeout is env-pinnable (WORKTRUNK_TEST_PROBE_TIMEOUT_MS, set to 60 s in the static test baseline; production keeps its 5 s bound), and the discovery poll uses the suite's 60 s presence-poll convention. Looped 15/15 green at load average ~60, where the previous shape failed 2/10.

Not covered here, noted as follow-ups: benches still spawn env!("CARGO_BIN_EXE_wt") directly (same hazard, separate runner, outside the guard's scan), and the reap "spared" branch has no deterministic end-to-end test (needs a PTY-held child).

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

The pinning approach reads well, and routing the mock-stub symlinks through wt_bin() (mock_commands::copy_mock_binary) closes the same window for the argv[0] mocks for free. Two stale-doc issues and one policy note.

Stale doc in src/git/reap.rs. The reap_pids_terminates_a_process unit test's doc comment still claims the controlling-terminal guard is covered in-process by the integration test — "Discovery and the controlling-terminal guard are covered in-process by the test_remove_reap_kills_process integration test (which calls processes_under / collect_reapable directly), so this focuses on the signalling half". This PR replaces that test's collect_reapable call with the /dev/tty read, so the integration test now calls only processes_under. collect_reapable's non-trivial path (and without_controlling_terminal's parse) is left with the discovery_on_nonexistent_path_is_empty unit test, which returns early on the empty-candidates branch, plus whatever the spawned wt subprocess covers. Worth rewording so the claim matches what the suite actually does after this change.

Not approving — data-safety surface. Per this repo's tend review policy the wt remove --reap path is a hold-for-human surface: the diff changes the bound on the ps probe that feeds the controlling-terminal guard, i.e. the gate whose own module docstring names "an editor with unsaved buffers" as what it exists to protect. Nothing here looks wrong to me — the production default stays 5s, and both timeout paths still fail safe (without_controlling_terminal → empty set → nothing reaped; processes_under → empty vec) — but the verdict is yours rather than mine. One thing to weigh explicitly: probe_timeout() reads WORKTRUNK_TEST_PROBE_TIMEOUT_MS in the shipped binary with no cfg(test) gate, so a user with that variable set moves a data-safety-relevant bound. That matches the existing WORKTRUNK_TEST_DELAYED_STREAM_MS precedent in shell_exec, so it's within convention — just noting it's now true of the reap gate too.

[worktrunk-bot]

The stale-doc point from my last review is addressed — I checked the reworded claim against the suite rather than taking it at face value: parse_ps_tty_classifies_terminal_presence / parse_ps_tty_ignores_unparsable_lines do cover the classification, and collect_reapable now has no in-process caller in the integration suite (only discovery_on_nonexistent_path_is_empty's early-return path plus the spawned wt), so the comment matches what runs. The doc re-home is right too: configure_pty_command_carries_the_git_config_floor has its paragraph back and the pin test keeps only its own.

The two new arm tests look correct to me. pin_test_binary_rides_out_the_uplift_window is safe against the sub-race where try_pin stats the file between fs::write's create and its write — the hardlink shares the inode, so the post-join read sees late binary whatever length the key was computed from. pin_test_binary_surfaces_non_transient_errors gets ENOTDIR from metadata, which is the Err(e) => arm rather than the NotFound retry, and the #[cfg(unix)] note is accurate — Windows resolves <file>\child to ERROR_PATH_NOT_FOUND, so there it would spin to the 10s deadline and panic with the other message.

Still not approving, for the same reason as last time rather than a new objection: wt remove --reap is a hold-for-human surface under this repo's review policy, and the diff touches the probe bound feeding the controlling-terminal guard. Nothing here reads as wrong to me — the verdict is yours.