[Bug][Test] reload-resume free-flow test times out under full-suite load

[N1k4G]

tests/reload-resume.spec.js:150 intermittently fails under full-suite load:

reload: an ongoing free-flow effect (deadline, drain target,
consumption multiplier) survives a real reload

What is known

• Pre-existing. Reproduced on clean main with the fix: give the diver a body instead of colliding on its centre #129 branch stashed and its new spec moved aside.
• Only under full-suite load. Failed 1 of 3 full npm run test:e2e runs; reload-resume.spec.js on its own passed 5/5.
• It is a timeout, not a wrong value. The failing run took 30.1 s; passing runs take 2.0–2.4 s. No assertion diff was produced — the whole test times out.

What is not known

The cause. Unlike #126, there is no diagnosed race here: that one compares a HUD snapshot against a later pagehide save, and buoyancy momentum accounts for the delta. This one gives no assertion failure to reason from, only a wall-clock blowout an order of magnitude past the normal run.

Worth establishing first:

• Which step stalls — the reload, the resume, or the free-flow state settling.
• Whether it is contention (the suite runs workers: 1, but the static server and browser are shared) or a genuine deadlock in the resume path that only a loaded machine exposes.
• Whether the 30 s is Playwright's default timeout or an internal wait.

A trace or video from a failing full-suite run would settle most of that; --trace on-first-retry would capture it cheaply.

Relationship to #126

Split from #126 on review. Both are e2e races and may share timing pressure under full-suite load, but they need different fixes and different closure criteria:

• [Bug][Test] wreck-slice depth assertion races the simulation #126 has a diagnosed snapshot/save race and a clear fix direction — compare like with like.
• This one is an undiagnosed whole-test timeout, and the first work is diagnosis rather than a fix.

Fixing #126 would not close this, and vice versa.

Why it matters

Between them, these two make a green verify weaker evidence than it appears. That is worth fixing on its own terms — CI has been used repeatedly as the basis for merge decisions.

[N1k4G]

The pattern is broader than one spec

Post-merge runs on main at e7bd472 (#129) — three different specs now fail intermittently under full-suite load, never in isolation:

Spec	Signature	Alone
reload-resume.spec.js:150	page.reload: Test timeout of 30000ms exceeded	5/5 pass
wreck-slice.spec.js:69	depth 27 m vs 28 m (#126)	4/4 pass
game.spec.js:4	not captured — whole test	3/3 pass

Across five full-suite runs on main, two came back clean (33 passed) and three had one or two failures between them.

This looks less like three independent bugs and more like the suite not coping with its own load. All three are slow, browser-heavy specs, and the failures are timeouts or a value read a beat late rather than wrong logic. #126 is the one with a diagnosed mechanism; these others may simply be that same timing pressure hitting whatever is slowest on a given run.

Worth checking early, before chasing individual specs:

• The globalSetup static server is shared across all specs; whether it is a bottleneck under sequential load is unmeasured.
• workers: 1 means everything is sequential, so a slow browser teardown pushes into the next spec.
• Whether the 30 s ceiling is Playwright's default test timeout or an inner wait.

If it is systemic, one fix closes all three. If not, this issue stays scoped to the reload-resume timeout and the others get their own.

Not a regression from #129. game.spec.js passes 3/3 in isolation, and one full run at the same commit was completely clean.