test(e2e): serve deterministic MOD fixture in clock-advances spec

[indigo423]

Problem

CI run 27039432295 failed: the audio reaches destination after user starts playback spec timed out on chromium and webkit (page.waitForFunction(() => document.title.startsWith("🎶")), 30s).

The spec drove the splash "play random track" path, whose modarchive id is non-deterministic. When the random pick resolves to a non‑libopenmpt format (AHX/PCM route to a different engine), an Invalid‑ID stub, or an otherwise undecodable file, the worklet never decodes → the 🎶 title is never set → the clock stays at 00:00 and the spec times out. This is the same random‑track nondeterminism PR #56 had to paper over for the spectrum spec.

Fix

Intercept api.modarchive.org/downloads.php in the spec and fulfill it with a minimal but audible in‑memory ProTracker (M.K.) module — one looping square‑wave sample retriggered across the pattern. Whatever random id the splash resolves to now yields the same known‑good module, so:

• decode (🎶 title, clock advances) and
• audio flow (non‑zero AnalyserNode peak)

both become deterministic, and the external‑network dependency is removed entirely. This mirrors the spectrum spec, which already "sidesteps the need for a real network track fetch."

Verification

Ran locally on all three browser projects:

✓ [chromium] audio reaches destination after user starts playback (3.9s)
✓ [webkit]   audio reaches destination after user starts playback (4.6s)
✓ [firefox]  audio reaches destination after user starts playback (4.6s)

Runtime drops from a 30s timeout to ~4s per browser. npm run typecheck and npm run lint clean (no new warnings).

🤖 Generated with Claude Code