test(core): the room-external stop tests give the child a fixed ~170ms window, so any loaded box fails them #3103

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 9f5365489b1d425a846a20406cdc141b
Branch: dev/1-room-external-ready
Base: 5cb1692
At: 2026-11-15T04:26:09Z

Bot: FlyBot Dev-1
Tier: T1 (core/test/** and its patches/ds-bot/files/test/ mirror; no product code)

What is wrong

core/test/room-external.test.js gives the external-room child a fixed ~170ms window and then asserts the child received the stop line. On a loaded box the child has not finished starting and draining stdin inside that window, so the driver's own SIGTERM (correct behaviour) arrives first, SEEN stays empty, and the test burns its full 4s waitFor budget.

Evidence on live main 5cb16923 (Dev-1, reproducible):

• Test side: :109 sleeps a fixed sleep(120) and then cancels; :114 waits for "type":"stop" in SEEN with a 4000ms budget; the observed failure is 4157ms — 120 + 4000 + overhead, matching the 4162ms seen in a real npm run verify run.
• Driver side: endChild writes the stop line and then sends SIGTERM after TERM_GRACE_MS = 50 (core/src/host/room-participant-external.js:23, :244). The driver is doing what it documents — stop is a courtesy, the signal is the fallback — so this is not a product defect.
• Load sensitivity measured: 8-way idle 8/8 green (20/20); the same file pinned with taskset -c 0 next to 6 CPU hogs is 2/2 red with the same not ok 5 … timed out waiting for the child. Child "spawn → first stdin drain" latency: 0 hogs 82–95ms (12/12 see the stop), 1 hog p50 178ms / max 205ms (5/12), 2 hogs 0/12. The 170ms window is the whole margin.
• Same class, same failure line: :191 (the #2634 case) goes red with the identical error in the same runs.

Expected: neither test depends on how fast the child starts. This is test-only; the driver and TERM_GRACE_MS stay as they are.

Scope

Test-only. The children in this file are inline -e scripts written by the test (:103, and the STUBBORN/HELD fixtures), so nothing under core/src/** changes and the driver keeps its current stop/SIGTERM behaviour.

• core/test/room-external.test.js:109: replace the fixed setTimeout(120) with an observable precondition — wait (bounded) for the child to prove it is reading, e.g. the "type":"turn" line already appended to SEEN, or a ready marker the child writes as soon as it attaches its stdin handler. Then cancel. The turn before stop ordering assertions stay exactly as they are.
• Same treatment for the #2634/#2957 regions where a fixed window or an unqualified 4s wait stands in for "the child is up" (:188).
• Keep every existing assertion (order, one stop line, null turn). Do not widen a budget to make a flake pass quietly: the wait must be event-driven, with a bounded failure that names what never arrived.
• If core/test/room-external.test.js has a generated mirror under patches/ds-bot/files/test/, it is regenerated in the same commit (generate must be a no-op afterwards).
• No TERM_GRACE_MS change, no product behaviour change, no new dependency.

Acceptance

• Deterministic red evidence, not a load lottery: (a) a test that fails with a named error when the ready handshake never arrives, so the failure points at the handshake instead of a 4s timeout; and (b) the reproducible recipe — taskset -c 0 plus CPU hogs — is 2/2 red on the base source and green on the fix, recorded in the PR.
• Full TZ=UTC npm run verify exit 0, and the file green 3 times in a row under the pinned-plus-hogs load.

Dedupe (live main 5cb16923, 2026-11-15)

Searched open and closed issues for room-external, timed out waiting for the child, TERM_GRACE_MS: #2962/#2957 fixed the teardown race (temp dir removed before the child exited) and #2634 is the stop-path bug this test covers; none of them changes the fixed sleep this issue is about. #1164 established the stop escalation and its wording.