ci/packets: test-issue-1692 packets-init-parallel E2E fails repeatedly — regression or flake? #439

Problem

test-issue-1692-packets-init-parallel-e2e.js ("first table row appears < 3000ms despite 4000ms /api/observers stub") now fails repeatedly in CI, with page.waitForSelector: Timeout 10000ms exceeded:

• master run 38409905842 (4c7a1ca5, the merge of fix(packets): honor channel filters for live updates #423);
• PR fix(ops): serialise SQLite backups per container (#403) #424 run 38411298858 (1db356cf);
• PR fix: Follow-ups to #352: My Mesh cadence test gaps, silent health errors, flaky channel test (#384) #397 (06:51Z today).

The test pins Kpa-clawbot#1692: /packets must render rows without waiting for loadObservers. A 10 s timeout means the first row never appeared, so this may be a real regression from the recent merges to public/packets.js and related code (e.g. #373, #394 and #402 XSS escaping, #367 and #398 canonical hops, #387 SRI-pinned CDN assets, #423 live channel filter), not only flakiness.

Required work

1. Reproduce locally against a local server with the CI fixture. Run the test 10× on current master and on 6444294d (v0.2.3) or another known-good base, and report the failure rates.
2. If it is a regression: bisect the merges since v0.2.3 to the culprit commit, fix it (packets init must not block on observers), and add/keep the regression test.
3. If it is genuinely timing-flaky: find the cause (e.g. CDN script load under SRI, runner load) and make the test deterministic without weakening what bug: /packets init() serializes loadObservers→loadPackets — 25-40s time-to-first-row on slow links (root cause of #1662 flakes) Kpa-clawbot/CoreScope#1692 pins.
4. Report the evidence (failure rates, bisect result, root cause) in the PR.