fix(ssm): wait on the condition, not on 5ms (#61)

[scttfrdmn]

Closes #61.

Four assertions in src/ssm/session.test.ts slept setTimeout(r, 5) for an async chain whose duration is a property of the machine, not of the code: the inbound handler awaits WebCrypto digests before ACKing, and markReady is invoked with void, so nothing awaits its flushPending. 5 ms was enough on an idle laptop and not enough alongside 29 other test files in parallel CI workers.

What each sleep was actually waiting for

Each is now a wait on that condition instead of on a duration:

was	now waits for
:141 — waitForSends(ws, 3).catch(() => {}) + 5 ms	s.ready. HandshakeComplete sends no frame back, so ready is the only observable effect — the .catch(() => {}) on a send-count wait was standing in for a condition it couldn't express, and goes away with it.
makeReady	s.ready before clearing ws.sent. A premature clear drops the flushed frames the caller's assertions then read, which is why the helper now takes the session and not just the socket.
the queue-then-flush test	a flushed Output frame
the channel-closed test	onClose having fired and the socket closed

waitFor(pred, describe) polls on a 1 ms tick with a 2 s ceiling. It takes a describe string because a CI timeout message is the only diagnostic anyone will ever see of a failure here. waitForSends becomes a thin wrapper over it.

sentFrames/inputFrames extract the repeated deserialize-and-filter. Worth noting: the session sends Uint8Arrays, not ArrayBuffers — my first cut of sentFrames filtered on instanceof ArrayBuffer and silently matched nothing. That's a quiet way to write a test that can never fail, so the helper filters out the one string send (the token JSON) rather than filtering in on a binary type.

Why this is worth more than an ordinary flake fix

The flakiest of the four covers input being queued rather than dropped — the terminal's core correctness property. A test everyone learns to re-run is precisely how a real regression in the flush path gets waved through.

Verification

• The failure mode, demonstrated rather than asserted. I could not reproduce the CI flake locally even under 8-core load, so instead of claiming a repro I made the flush path take 25 ms and ran both versions: the old sleeps fail exactly the test Flaky test: ssm/session.test.ts handshake-flush assertion races a fixed 5ms setTimeout #61 names, the condition waits pass.
• Four mutations of session.ts, each still caught: no-op flushPending (1 fail), handshakeDone never set (3 fails), no onClose on ChannelClosed (1 fail), socket not closed (1 fail). The waits fail on broken, not merely on slow.
• Ten full-suite runs under 8 busy cores: 591 passing, no flake.
• The file's own runtime went from ~2 s of sleeping to 12 ms.

Other setTimeout(r, 0) calls in src/ui/*.test.ts are left alone: a zero-delay yield is a deterministic macrotask boundary, not a bet on how long something takes.