fix(test-helpers): kill the whole watch process group so teardown stops leaking orphans

[LanNguyenSi]

watch-mirror-delete.test.ts flaked under suite load and the runner stalled long after every test had gone green. The cause is not the test content.

spawnWatch's child is the tsx launcher, not the process that runs src/main.ts. tsx spawns a second real node process with stdio: inherit, so that grandchild holds the same stdout/stderr pipe fds. SIGKILL cannot be caught or relayed, so the deadline path killed the launcher and left the grandchild reparented to pid 1, still holding the pipe open. Nothing reading it ever saw the stream close. (SIGINT and SIGTERM happen to be relayed by tsx today, so the graceful path was not the leak. That is not something to rely on, and the comments say so.)

spawnWatch now spawns detached, making the launcher its own process group leader, and stopWatchProcessGroup signals the whole group via process.kill(-pid, sig). That is PID-scoped: it can only ever reach descendants of that one spawnWatch call, never a name pattern. Graceful SIGINT with a 2s grace period, then SIGKILL. runWatchTick's teardown always attempts it rather than trusting the launcher's exit state.

Review found three gaps in the first cut, all fixed here:

• Detaching costs the free cleanup the old code got from sitting in the runner's own process group, where a Ctrl-C on npm test reached the children too. Measured: post-change the same signal left 2 survivors. A module-level registry plus exit/SIGINT/SIGTERM handlers now SIGKILL any still-tracked group as a last resort.
• Signalling can throw on a non-ESRCH errno. The throw happened before reject(...) in the deadline timer, so it became an uncaught exception that killed the whole test file instead of failing one test, and in the finally it replaced the real error. The deadline path now rejects before it signals, and EPERM is treated like ESRCH.
• No regression guard. Reverting either half of the contract is silent: kill(-pid) then throws ESRCH, which the helper swallows, so teardown degrades to a no-op with every existing test still green. The new watch-teardown-guard test pins the group actually dying, using the parent-side pipe close as the observable. Both revert arms were mutation-tested outside the repo and each fails this guard.

Evidence. The reviewer reproduced both arms under one instrument: the pre-change helper hung the runner for the full 10-minute cap, the fixed helper exited in 24.9s with zero survivors. The implementer's own negative control (both files reverted, heavy synthetic load) reproduced the failing test plus two simultaneous ppid-1 orphans. After the fix: 158 tests green across repeated runs, zero orphans in every run, typecheck clean.

TICK_TIMEOUT_MS stays at 20000ms; no clean-condition run came near it. Raising it for CI's weaker runner would need CI-side evidence we do not have.

One acceptance criterion is not met and is worth recording rather than glossing: the spec asked for a wall time around 30s, and runs land at 41-60s. The reviewer traced that to run-schedule-escalation.test.ts (about 29-59s on its own), which already behaves that way on origin/master. Not attributable to this change.

Refs: task c71de504