test: the `Connection closed.` cascade after a stalled browser file is unreproduced

[AlexJeffcott]

Summary

polly#177 reported that once one browser-tier file times out, every later file
fails with Connection closed. — one stall turning 5 healthy files into 5
failures. The fix for it landed on fix/177-modal-render-loop unverified
against that symptom, because the symptom did not reproduce.

What is known

The runner now gives each file its own browser context, bounds teardown at 5s,
and relaunches the browser if browser.connected is false
(tools/test/src/browser/run.ts). scripts/e2e-browser-runner-stall.ts proves
healthy files run either side of three deliberately stalled ones, and asserts
the output contains no Connection closed.

What is not known

Whether that is the mechanism that produced the original cascade. Two
whole-tier runs of the eal repro were attempted with a stalled chat.browser.tsx
in the middle; both times the later files ran normally on the old code, so the
cascade never occurred and the fix was never exercised against it.

Readings from those attempts:

Attempt	Result
eal whole tier, POLLY_BROWSER_TIMEOUT_MS=10000	61 passed, 1 failed — chat timed out, all 8 other files ran
eal whole tier, second attempt	same

The original report used a 300000ms timeout, so a long-held wedged renderer may
be a necessary condition — a page spinning at 100% CPU for 5 minutes is a
different load on the browser process than one spinning for 10 seconds.

Next step

Reproduce with POLLY_BROWSER_TIMEOUT_MS=300000 against a build with the
polly#177 Modal defect restored, and watch whether the browser process dies. If
it does, confirm the relaunch path recovers; if the cascade cannot be produced
at all, close this and treat the isolation work as a standing guard.

[AlexJeffcott]

The cascade did not reproduce

Ran the experiment this ticket names. The polly#177 Modal defect was restored in
eal's installed polly (dist/src/polly-ui/index.js: const entry = { id, onClose },
and onClose back in the overlay effect's dependency array), and the whole eal
browser tier was driven by the pre-fix runner — 355a3d5^, one shared
browser, browser.newPage(), no per-file context, no relaunch, no bounded
teardown — at POLLY_BROWSER_TIMEOUT_MS=300000.

Two arms: eal at main (c0a7d11), and eal at this ticket's own repro commit
1c3d1cc.

Arm	eal commit	Trials	300s stalls	Connection closed.	Files after the stall
1	c0a7d11	5	1	0	5 of 5 ran
2	1c3d1cc	3	2	0	5 of 5 ran

Three full 300 000 ms stalls in chat.browser.tsx, on the runner that has none
of the isolation work. In all three the browser process survived, every later
file ran normally, and the stalled file was the only failure:

[browser-runner] running chat.browser.tsx
  ❌ timed out after 300000ms waiting for __pollyReport — the in-page suite never reported
[browser-runner] running nav.browser.tsx
  ✅ shell navigation > the landing launcher shows at / and lists the apps
  ...
[browser-runner] 94 passed, 1 failed

The duration hypothesis is therefore refused. A renderer wedged for 5 minutes
does not kill the browser process on this machine, and 300 000 ms behaves the
same as the 10 000 ms attempts already recorded here.

Two other readings

The defect is probabilistic, not deterministic. 3 stalls in 8 whole-tier
trials, and 1 of 1 when chat.browser.tsx runs alone. All three eal consumers
pass an inline onClose (nav-drawer.tsx:20, chat-panel.tsx:50,
specimens.tsx:649), so the defect is live in each; whether the loop closes
depends on run timing.

polly#177's "0.0% CPU, 14 samples over 42s" was a mis-sampled process. The
restored defect wedges the renderer at 100% CPU, and the current runner names it
correctly: "the page never yielded its main thread, so JavaScript is still
running." Recorded here because that reading is what sent the original
investigation at a browser-level cause for three days.

Closing

Per this ticket's own next step: the cascade cannot be produced, so the isolation
work in tools/test/src/browser/run.ts stands as a standing guard rather than a
fix for a demonstrated symptom. scripts/e2e-browser-runner-stall.ts (tier case
browser.runner-stall) keeps that guard honest at an 8 s deadline. A 300 s case
is not added: it costs 5 minutes of tier time to assert what these 8 trials
already read.

Not tested: a machine under memory pressure, and the Chrome build that shipped
with puppeteer at the time of the original report.