SPA canary-under-load: Core Web Vitals from browsers running concurrently with the k6 baseline #386

Slice 2 of 3 from #277. Depends on the harness from #385 (the E2E smoke slice) — this reuses its project, its cast fixture and its browser resolution.

What this measures, and why k6 cannot

#243 gives server-side percentiles at the protocol level, with no browser in the loop. This slice runs 1–2 Playwright browsers concurrently with the k6 load and captures what only a real browser can see:

• Core Web Vitals — LCP, INP, CLS.
• Page-load timing under a saturated backend.
• Asset loading (the hashed bundles, fonts, icons — anything the SW precaches).
• Visual correctness while the backend is saturated — a screen that renders an error state, an empty table, or a spinner that never resolves is a real regression even when the server's own percentiles look healthy.

Playwright is never the load generator. 1–2 browsers is a canary, not a crowd; k6 stays the crowd. A canary that adds meaningful load would change the number it exists to observe.

Metrics sink (settled with the owner: both)

• Playwright's own HTML report + trace — the raw artifact, for debugging a specific bad run.
• Folded into the Release rehearsal: day-in-the-life simulation of 10 users (all roles) with container-resource + HTTP-traffic monitoring #243 findings doc — a CWV summary appended to tools/simulation/findings/ (rendered from TEMPLATE.md by run-baseline.sh), so the browser experience sits beside the server percentiles from the same run. That adjacency is the entire point of running them concurrently; two separate documents would leave the correlation to the reader.

Acceptance

• A canary run alongside a k6 baseline produces CWV numbers attributable to a specific rep of that baseline.
• The canary's own contribution to load is stated, not assumed negligible.
• The report canary at the maximum supported date range (Bound production report workload, query size, and concurrency #311) captures browser responsiveness beside server latency, without exceeding the documented bound.
• A degraded-under-load result is reported honestly, with the run it came from — not smoothed by re-running until it looks good.

Tracked in epic #15, under #277.