Follow-up to commit `029329af`: a verification sweep (5×) showed
the `pcm.size > warmupSamples` hard floor on
`chromium_listener_speaker_hot_swap_does_not_crash` flakes 3/5 —
empirical capture varies 2880–7680 samples (= 60–160 ms TOTAL),
straddling the 4800-sample warmup threshold. The browser-side
@moq/lite 0.2.x re-attach behaviour across `Active::Ended →
Active` is fundamentally unreliable; ANY hard floor that
excludes the regression mode ("swap killed the WT session
entirely") fail-flakes because the steady state itself sits
right at that threshold.
Per `2026-05-07-tighten-cross-stack-assertions.md`'s Risk § option
(a) — "If any scenario fail-flakes after tightening, [...] revert
the tightening on that scenario" — this commit reverts the
hot-swap floor to a documented soft-pass that prints to
System.err when triggered. T12 (group sequence carry across
hot-swaps) is still asserted by the hang-tier counterpart
(`speaker_hot_swap_does_not_crash` in `HangInteropTest`), which
hard-asserts the full post-swap window decodes the 440 Hz peak.
The deferred "browser hot-swap re-attach" follow-up in
`2026-05-06-cross-stack-interop-test-results.md` captures the
underlying @moq/lite client work that would let this scenario
become a hard-floor test in the future.
Claude
f8dc9c59be