fix(ci): close the two post-#370 CI races - denylist hydration vs sw/web-fetch, and the Firefox Run-control probe

[jonybur]

What broke

Three intermittent CI reds surfaced after #370 merged, all races rather than code breaks (each passed on other runs of identical trees):

1. packaged page boot (red on main's Add first-class Firefox Notebook modules #370 merge run). The preview remote-import probe failed with The sensitive-origin policy is unavailable after 0 fixture requests. The denylist seed hydrates async at SW boot and webFetch's getDenylist does a synchronous readiness check, so a sw/web-fetch request (Notebook module fetch, VM egress) racing a cold start was refused instead of waiting. Every tool-dispatch path already awaits denylistReady in buildToolContext; this engine route was the one fetch boundary that did not.
2. Firefox suite: the Run-control probe read notebook.js the instant the button flipped to Stop, but the flip happens at run-reserve time, before js/eval's awaited mirror of the agent code lands in OPFS - the single-shot read saw the previous run's code. The product ordering is correct (reserve first prevents double-runs; the mirror completes before the run starts); the test's read was the bug.
3. Firefox suite: the remote-fetch stop probe slept a fixed 150ms then aborted - on a slow runner the abort landed before the resolver had issued the slow fetch, so the fixture saw 0 requests instead of the in-flight cancel the test pins.

What changed

• sw/web-fetch awaits an injected awaitDenylistPolicy gate (requireDenylistPolicy(await denylistReady), defined next to denylistReady, wired shorthand) before any fetch work. A racing request waits out the one-time load; a genuinely failed hydration still refuses before any egress - fail-closed unchanged, and the sync check in getDenylist stays as the last-resort chokepoint for other direct callers.
• The Run-control probe polls the notebook.js read (bounded) until the mirrored content appears.
• The stop probe aborts only once the fixture's new status endpoint confirms the slow request is on the wire (read through the same audited sw/web-fetch relay the resolver uses; single injected block because geckodriver gives each script a fresh sandbox). elapsedMs now measures abort to settled - the prompt-stop property - instead of including run setup.

Residual (flagged, not changed)

The neighboring timedOutFetch probe has a smaller latent race of the same family: its 400ms eval deadline must fire after run setup has issued the slow fetch. It has never failed in CI and fixing it deterministically means changing its contract (the deadline is intrinsic to the eval), so it is left for a deliberate follow-up if it ever fires. The dweb two-peer red on this PR's second run is unrelated: the only diff from its green first run is the Firefox harness file, and the lane passed on the ten runs before - an infra blip, re-exercised by this push.

Verified

• Two new bun tests pin the route gate (racing fetch waits, order-asserted; failed hydration refuses before vmHttpFetch), revert-proven red without the fix.
• Full local gate set green: bun suite (5665), typecheck, lint, boundary, imports, tscheck, gen drift, copy + source hygiene, invariants, in-browser (864), check:pages both channels, and the full Firefox runtime suite (all checks + 858 Gecko browser tests) against pinned Firefox 153 + geckodriver 0.37.1, green including all three previously-racing probes.
• packaged page boot already ran green twice on this PR with fix 1 in place.

[github-actions]

Visual regression

✅ No visual drift. Every state renders identically to the committed baselines.

📸 Browse the visual gallery — 54 baseline screens (light + dark) as of this commit.