fix(ssh): concurrent launches on one remote home share one server#32587

Problem

Two SSH launches against the same remote T3 home at the same moment (two desktops reconnecting to one host after its server stops, or two aliases for one host) both pass the "is a server running" check, pick the same port and start t3 serve. The second server loses the home's owner lock and exits with ServerAlreadyRunningError, but its launch writes its dead child's PID to ~/.t3/ssh-launch/<key>/pid last. The next connect sees server-runtime.json naming a different PID and adopts the live server as external, so a desktop update no longer replaces it and Disconnect no longer stops it.

Reproduced on main 25bf84ab07 by rendering REMOTE_LAUNCH_SCRIPT for the archive runner 0.1.8-nightly.20261107.4314 and running two launches at once in a throwaway HOME on Linux (dash as sh): 3 of 3 attempts (fresh home, runtime already installed, two state keys sharing one home) ended with the record naming a dead PID, and the next connect printed "serverKind":"external".

Change

REMOTE_LAUNCH_SCRIPT in packages/ssh/src/tunnel.ts holds one lock per remote T3 home (~/.t3/ssh-launch/.launch.lock), using the same noclobber PID-file idiom as the runner's install lock. A launch takes it after the runner is resolved (a cold archive download stays outside it) and keeps it through the runner comparison, reading the records, the start and the readiness wait. A waiting launch then finds the first server:

• on the same alias, through the shared record (managed);
• on another alias, through server-runtime.json (external), or, when that file is missing or not yet written, through the other alias's launch record: a live managed PID whose port answers the existing reuse probe is adopted as external.

Details:

• The server answers HTTP before it writes server-runtime.json, so after a fresh start the launch keeps the lock until that file names its PID, for at most 10 s. A server that publishes later or never is still found through its launch record.
• The runner file is compared and replaced under the lock, so a waiting launch on the same record does not see a "changed" runner and restart the server the first launch just started.
• A lock left by a killed launch is taken over only under a short recovery lock (.launch.lock.break) that re-reads the owner, so a waiter that judged an older lock stale cannot remove a newer launch's lock. No launch removes another's recovery lock: one is left behind only by a SIGKILL inside those few lines, and waiters then fail after the wait limit with a message naming the file to delete. HUP, INT, PIPE and TERM exit through the cleanup, which removes only locks this shell owns.
• The lock wait is derived from the existing timeouts (82 s). The node-script runner's SSH timeout becomes that wait plus the previous 90 s (172 s); the archive runner's 900 s still covers install wait, download, lock wait and readiness. The tunnel connect timeout from main stays at the 90 s base.

Scope and approval

Fixes pingdotgg/t3code#32549

Triaged via the automated issue flow; GitCafe issue #32549.

Verification

• vp test run packages/ssh/src/tunnel.test.ts: 15 passed. The test ssh tunnel scripts > concurrent launches on one remote home record the server that owns it runs the real launch script under local sh for two aliases sharing one temp home, with a fake t3 serve that takes an owner lock, and a pre-seeded stale launch lock, in two rows: runtime record published 1.5 s after listening, and never published. It asserts one managed and one external result on the same port, exactly one server process started, and that the record names the server that owns the home. Against main's tunnel.ts it fails (the second alias's server loses the home lock and the launch never becomes ready).
• vp run check:changed on f91433db1f (main merged, no packages/ssh change from main): format, lint, knip, typecheck (5 packages) and tests pass.
• Three review rounds, each by two independent reviewers. Round 1 found two races, both reproduced and fixed in 29975cd79c: a waiter could delete a successor's recovery lock and admit two launches, and a server whose runtime record arrived after 10 s was not found by another alias. Round 2: no code bugs. Round 3, on f91433db1f, two fresh reviewers: no code bugs, both MERGE.
• Proof audit: the fixture matrix (23 rows) was re-derived from the code at f91433db1f. Pass 1 found four rows without current captures (F01, F03, F12b, F19); they were captured on f91433db1f, and pass 2 is sufficient, with F12 and F19 rebuilt independently from the uploaded drivers. Rows F07-F10 (saved external port, invalid saved state, unready existing server, port selection failure) are paths the diff does not change and have no capture.

Evidence

Rows F01, F03, F12b and F19: before = merge-base d313b2aff3, after = f91433db1f, same drivers, same environment (index and drivers). The other rows: before = merge-base 0a9abddaee, after = 29975cd79c, whose packages/ssh is identical to f91433db1f.

Before = merge-base 0a9abddaee, after = 29975cd79c (the later merge of main touches no packages/ssh file). Ubuntu 24.04.4 x86_64, sh = dash 0.5.12-6ubuntu5, archive runner 0.1.8-nightly.20261107.4314 (0.1.9-nightly.20261110.4465 for F05), throwaway HOME; fixture rows use a fake t3 serve and say so. Index with every row, the "what else changed" list and all drivers: index.md. Matrix: matrix.md.

Cold archive launch, two aliases on one home, reconnect and lock-recovery interleaving (rows F04, F13, F16; F01 and F03 are recaptured above on f91433db1f) were captured on 6016bfa6a4 with the real archive runner; the later changes do not reach those paths (audit pass 2): transcripts and drivers.

What else changed: signal exits now end with exit status 1 instead of dying by the signal; a leftover recovery lock produces its own error message; on main, F05's concurrent update also hit a Permission denied race publishing the runner, which the lock removes.

Not checked: a real two-desktop run over SSH, macOS /bin/sh and zsh as sh (dash, bash and busybox ash were exercised). Older desktops do not take the lock and race as before.

AI-assisted; verified with the tests and tools listed above.