Decide whether the Chromium WPT parity gate enters CI

[lann]

With #26 fixed (PR #34), just wpt::parity-chromium is green and its
ratchet (parity/losses-chromium.js) records stably — the gate is no
longer blocked on its own machinery. Whether it joins CI is now purely a
provisioning and policy decision:

• Runner needs a Chrome 137+ binary (JSPI enabled by default from
  137). scripts/chrome.mjs resolves CHROME_PATH, a playwright cache,
  or system binaries; CI would need one of those provided (e.g.
  npx playwright install chromium or the browser-actions setup step).
• Cost/flakiness budget: the run spawns echod, a static server, and
  a headless browser; both legs complete in well under the 600 s
  timeout locally, but headless-browser steps are the usual flake
  source. Options: full gate in just ci, a separate non-required
  workflow, or scheduled.
• Ratchet ownership: once in CI, a Chromium behavior change (new
  Chrome version shifting its baseline pass set) fails the gate until
  just wpt::update-losses-chromium is re-run — pinning the browser
  version in CI would make that deliberate rather than ambient.

Doing nothing is coherent too: the gate stays a local/manual check, as
today, with the justfile note saying why.