fix(pty): guard node-pty's unlistened win32 conin socket, and harden Windows CI

[y49]

Closes #59.

Started as "is Windows CI even worth keeping?" — it had a ~10% red rate on a required check and, across its whole history, had never caught a product bug. Every red traced back to test fragility.

Investigating the most recent one reversed that. #59 is a real daemon crash on Windows, not the test-teardown noise it was filed as. The CI job had caught its first product bug and we had misfiled it.

The crash

node-pty opens two pipes to the ConPTY. The read side gets an 'error' listener; the write side does not:

// windowsPtyAgent.js:79 — conin, constructed with no 'error' listener
this._inSocket = new net.Socket({ fd: fs.openSync(term.conin, 'w'), readable: false, writable: true });

// windowsTerminal.js:54,90 — conout, listener present
this._socket = this._agent.outSocket;
this._socket.on('error', err => { /* ... */ });

Every pty.write() goes to that unguarded socket (windowsTerminal.js:123) and kill() destroys it (windowsPtyAgent.js:176). A net.Socket with no 'error' listener escalates any error to an uncaught exception, so a failed write takes the process down. Two triggers reach it: EAGAIN when conin's buffer fills, and a write racing kill().

tlive writes user keystrokes into the pty and kills ptys when sessions end, so on Windows a keystroke landing in the same tick as a kill crashes the daemon. Tests hit it first only because they start and stop ptys far more densely than a person does.

Fixed in three layers:

• win-conin-guard.ts attaches the listener node-pty is missing. This is the fix that stops the crash — it covers EAGAIN backpressure too, which has nothing to do with our lifecycle. Reaching through the private _agent is deliberate and is the only route: Terminal.on() forwards to the conout socket, so there is no public path to conin. The module records the node-pty version the shape was verified against, and degrades to a no-op rather than throwing if a future release renames it.
• disposePty() clears this.pty after kill, so a client Data frame already queued cannot reach a torn-down pipe. Defence in depth, and correct regardless of platform.
• Upstream report filed against node-pty so the guard can eventually be deleted.

Windows CI now covers the product, not just the test suite

install-smoke-windows installs the real packed tarball on windows-latest, then exercises the .cmd shim, loads node-pty from the global install, spawns an actual ConPTY, and runs the named-pipe daemon through start/status/stop.

Windows previously ran unit tests and nothing else, which is precisely why a genuine Windows crash could sit behind a "test flake" label. The Linux install-smoke job earned its place the same way, by catching node-pty 1.1.0 shipping no linux prebuild — invisible to unit tests, which install with a full toolchain present.

Not added to branch protection in this PR. It should accumulate a track record on real runners first.

The flake class that made the job untrustworthy

Fixed setTimeout waits sized for unix sockets, ahead of assertions that something had arrived. Windows named pipes are slower, so margins that hold on Linux do not hold there — that is both #45 and the expected +0 to be 1 red from last week.

Nine IPC/pty test files were reviewed; six needed changes, and 29 waits now poll for their condition through a shared until() helper. The other three — spawn, edit-queue, client-close — were deliberately left untouched, which is as much the point as the conversions: their waits are a bounded polling loop and two absence checks, and converting them would have been the mistake.

Deliberately not converted: absence and invariant assertions, which prove something did not happen. vi.waitFor returns on its first successful check, so a condition that is already true is asserted with zero elapsed time — converting those would silently gut them while leaving the tests green. Every retained fixed sleep is annotated with why.

Every retained fixed interval is an absence or invariant assertion, or an already-bounded polling helper, annotated in place with why it stays. Two sites are worth calling out because they are the trap in miniature:

• One assertion looked like an arrival but read its expected value off the very state it then asserted on, so it was already true before the action under test. Wrapping it in until() made it weaker than the 80 ms sleep it replaced.
• One sequencing wait has no daemon-observable substitute at all — on the suppressed grace path the handler returns before the observable is ever assigned. It stays a fixed sleep, widened, with the exit condition documented in place.

Also fixed

SessionHost initialised lastOutputAt at construction, so the first activity poll classified every session as running — 1000 ms elapsed is inside the 1500 ms window whether or not the child ever wrote anything. A silent session reported running for its first second, contradicting the contract in that file's own header. Activity now derives from observed output.

Verification

651 tests green; typecheck and build clean. Beyond that:

Controlled experiment on real Windows hardware. A VM that reproduces the flake class far more readily than GitHub's runners do — 90% vs ~10% — ran the full suite ten times on each revision. Same machine, same command:

	before (8b983db)	after (85150c7)
failures	9 / 10	0 / 10

The baseline failures were exactly the tests this branch converted, including the expected +0 to be 1 signature from CI.

install-smoke-windows verified non-vacuously. Its first run passed while its daemon step could not actually fail — pwsh does not halt on a native non-zero exit, and tlive stop exits 0 when nothing is running, so the verdict came from that alone. After gating each command, the step logs tlive daemon started (pid 2688) / daemon: running (pid 2688, uptime 0s) / tlive daemon: stopped, so the assertion demonstrably runs. That same run is also the first time tlive status's non-daemon output path has executed on real Windows.

What is not verified. write EAGAIN never reproduced on the VM — 40 single-file runs and 10 full-suite runs, before or after. The crash fix rests on the code-level argument, not a before/after measurement: the missing listener is a fact about node-pty's source rather than a hypothesis, but nobody has watched the crash stop on demand. #59's closing comment says so, and asks for a reopen rather than a new issue if it recurs.

Every commit was reviewed by an independent pass before the next one started; three of the plan's own technical premises were caught and corrected that way.