[Bug][Test] wreck-slice depth assertion races the simulation

[N1k4G]

tests/wreck-slice.spec.js intermittently fails its depth-restoration assertion:

Error: expect(locator).toHaveText(expected) failed
Locator:  locator('.wreck-hud dd').first()
Expected: "27 m"
Received: "28.1 m"
   at tests/wreck-slice.spec.js:69:55

Observed roughly once per two full npm run test:e2e runs. The spec alone passed 3/3, so it needs the fuller run's timing to surface.

Not a restoration bug

The test compares two different moments rather than one value against itself:

• wreck-slice.spec.js:64 reads the depth off the HUD, which is a rendered snapshot of a particular frame.
• The reload's pagehide handler (wreck-app.ts:172) then saves the authoritative state, which is still moving.

Buoyancy momentum between those two moments accounts for 27.0 → 28.1 m. Restoration is doing its job; the assertion is racing the simulation.

Why it matters beyond the one test

An intermittently red suite weakens every "CI is green" claim made against it. This was noticed precisely because a green run was being used as evidence that something else was correct.

Suggested direction

Compare like with like — assert against the value that was actually persisted rather than against a HUD frame captured earlier. Options, roughly in order of preference:

1. Read the saved payload back and assert the restored state equals it.
2. Quiesce the dive before saving (zero vertical velocity, or pin depth) so the two moments cannot diverge.
3. Read the authoritative depth rather than the HUD text at line 64, and allow a tolerance that reflects one frame of movement.

Option 1 is the one that actually tests restoration; 2 and 3 mostly make the existing assertion honest.

Not blocking

Split out of #125 deliberately, and confirmed to predate it — reproduced on that PR's branch with its test changes stashed.

[N1k4G]

A second flake in the same suite

Found while running the full e2e suite on #129. Same class, different spec:

tests/reload-resume.spec.js:150
  reload: an ongoing free-flow effect (deadline, drain target,
  consumption multiplier) survives a real reload

Also pre-existing. Reproduced on clean main with the #129 branch stashed and its new spec moved aside: failed 1 of 3 full runs. Running reload-resume.spec.js alone passed 5/5.

The timing signature points the same way as the depth assertion above — the failing run took 30.1s against 2.0–2.4s when it passes, so it is a timeout rather than a wrong value.

Recording it here rather than opening a second issue: both are e2e races in reload/persistence paths, and the useful outcome is a suite that is trustworthy rather than two separate fixes. Worth widening this issue's scope, or splitting once someone looks at whether they share a root cause.

Observed failure rates, full-suite runs:

Spec	Failures
wreck-slice.spec.js:69	~1 in 2
reload-resume.spec.js:150	1 in 3

[N1k4G]

Split the second flake out to #130 on review, and narrowed this issue back to the wreck-slice depth assertion.

The two need different fixes and different closure criteria: this one has a diagnosed snapshot/save race with a clear direction (compare like with like), while #130 is an undiagnosed whole-test timeout where the first work is diagnosis. Fixing either would not close the other.

They may share timing pressure under full-suite load — worth revisiting if a common root cause turns up.

[N1k4G]

Fixed in #132 (e049ebd).

The assertion compared two different moments, exactly as diagnosed: it read .wreck-hud dd — a rendered snapshot — then reloaded, and pagehide saves controller.authoritativeState, which has kept moving. Buoyancy momentum explains 27 m read against 28.1 m restored.

It now reads back what was actually persisted and asserts restoration reproduces that, which is the property worth testing. Reverting to the HUD-snapshot comparison fails the test.

The load that exposed it is gone too: the suite was running seven workers by default, and is now capped at four — 6 of 6 clean runs against roughly 40% failing before.