feat(ci): daily scheduled Lighthouse CI audit for the frontend

[Moonwalker-rgb]

What

Follows up PR #195 by promoting Lighthouse CI from a local-only opt-in to a daily scheduled GitHub Actions workflow. The CI runs @lhci/cli against the production build once a day at 00:30 UTC, gates accessibility and SEO, and publishes the per-route HTML report as a CI artifact so regressions surface within hours rather than at the recipient's keyboard.

This is non-gating for PRs (PR #195 keeps jest-axe as the fast pre-merge gate) but is the canonical source of truth for whole-page a11y + SEO going forward.

Changes

• .github/workflows/lighthouse.yml (new) — scheduled cron 30 0 * * * (sidesteps the 00:00 queue spike), workflow_dispatch for manual re-runs, concurrency: cancel-in-progress so a slipped schedule doesn't queue stale runs, permissions: contents: read, NEXT_TELEMETRY_DISABLED=1 + NODE_ENV=production, pnpm + actions/cache@v4 with a Node-version-aware key (no stale store restore on Node upgrades), explicit pnpm build before autorun, actions/upload-artifact@v4 for 14-day retention of ./lhci-reports.

• app/frontend/lighthouserc.json (replaces the placeholder) —

  Field	Value	Why
  startServerCommand	pnpm start	Boots the prebuilt app
  startServerReadyPattern	"Ready in"	Substring-matches Next.js 16's ✓ Ready in Nms
  startServerReadyTimeout	60000 (ms)	Generous buffer for cold runners
  numberOfRuns	2	Median over noise
  settings.preset	desktop	Reproducible across runners
  url	/, /en/dashboard, /en/help, /en/verification-review	All real [locale]/* routes
  categories:accessibility	error, ≥ 0.9	WCAG — non-negotiable
  categories:seo	error, ≥ 0.9	Public pages must be indexable
  categories:best-practices	warn, ≥ 0.8	Mostly about secure context
  categories:performance	warn, ≥ 0.5	Not gated — LCP scores flap
  categories:pwa	off	Not a PWA
  upload.target	filesystem → ./lhci-reports	Artifact upload; no external LHCI server

• app/frontend/LIGHTHOUSE_CI.md (rewritten) — operator playbook: assertion table, audited route list, how to fetch the artifact from a failed run, local-repro recipe with Chrome installed.

• app/frontend/package.json — @lhci/cli ^0.15.1 devDep, pnpm lhci:autorun script.

• pnpm-lock.yaml — updated for @lhci/cli.

Why a separate workflow

jest-axe (a11y.test.tsx, ~6 tests) is fast and deterministic, runs in jsdom, and is the right gate for PR diffs. Lighthouse is slow, requires a real Chrome + a built bundle + a running server, and is best run against the production output daily. The two are complementary, not redundant.

Caveats documented in LIGHTHOUSE_CI.md

• GitHub-hosted cron is best-effort — runs can be delayed 5–15 min or skipped under heavy load. Stale badge ≠ regression.
• The first run after this lands will populate ./lhci-reports and surface any pre-existing a11y/SEO failures; treat them as the new baseline.

Notes for reviewers

• Auth-gated [locale]/dashboard + verification-review render their shell for unauthenticated visitors (no middleware.ts in this repo). The audit scores what an unauthenticated user actually sees, which is the correct surface for an aid-recipient app.
• The cache key includes steps.node-version.outputs.node-version which is the documented output of actions/setup-node@v4. The restore-keys fallback is scoped to the same node version so a Node upgrade doesn't poison the fallback with a stale store.

Reviewers: @Lansa-18 @maramina for the workflow + config; @gbengaeben @CodeMayor for any Python-adjacent concerns (this is pure TS/CI, so unlikely).

[Moonwalker-rgb]

cc @Lansa-18 @maramina — frontend reviewers. Specifically curious about: (1) whether the four [locale]/* audit URLs match how you think about smoke coverage, (2) whether categories:performance should stay warn-only or get a tighter floor once we have a baseline, and (3) whether the lighthouse-reports artifact retention of 14 days is enough for trend review.