Follow-ups: harden the site performance / Lighthouse quality gate

[jmservera]

Context

PR #623 fixed the Lighthouse performance gate root cause: the CI served the build uncompressed (python -m http.server) while production (GitHub Pages) serves gzip/brotli, and each page was measured on a single noisy run. Fixes landed there:

• Page-scoped tool-page CSS bundle + repaired a broken cookieconsent-theme exclusion
• Median-of-3 Lighthouse measurement
• gzip-compressing serve (scripts/serve_static.py) matching production

These follow-ups build on that work. Thresholds must stay unchanged (perf 90 / a11y + best-practices 95 / CLS 0.1) — the goal is correctness and margin, not weakening gates.

Proposed improvements

• Extend page-scoped CSS bundling to other lean pages. Apply the tool-page split pattern to search, about, methodology, and privacy pages that also skip article/chart CSS, trimming render-blocking bytes site-wide. See layouts/partials/head.html.
• Add brotli to scripts/serve_static.py. GitHub Pages also serves brotli; negotiating br when the client accepts it makes the CI gate environment even closer to production.
• Document the Lighthouse gate methodology. Record the median-of-3 + gzip-serve rationale in docs/qa-gates.md so future maintainers do not revert to the uncompressed single-run server.
• Tighten the data-page CLS budget. The data page is highest at ~0.040 (threshold 0.1); reserve chart space to harden it before it can regress.
• Speed up the Production site job. Median-of-3 x 9 pages pushed the job to ~10 min; parallelizing per-page Lighthouse runs would cut wall-clock time.

Acceptance

• Each item is independently shippable and keeps all existing gates green.
• No Lighthouse threshold is lowered.

Follow-up to #623.