CI: Lighthouse performance report (advisory, non-blocking)

[rivassec]

What

Adds a scheduled, advisory Lighthouse CI performance report. Two new files, no existing workflows or content touched:

• .github/workflows/lighthouse.yml - weekly (cron: '17 6 * * 3', Wednesdays 06:17 UTC, offset from the other crons) + workflow_dispatch. Builds the site the same way deploy.yml / a11y-check.yml do (pip install --require-hashes --no-deps -r requirements.txt, then pelican content -o output -s publishconf.py), serves output/ with http-server on :8080, and runs @lhci/cli autorun.
• lighthouserc.json - collects the homepage and a representative article (/cryptominer-in-the-docker-layer.html), 3 runs, desktop preset. All assertions are at warn level (categories:* plus generous LCP/CLS/TBT budgets), so normal runs pass.

Why it is NOT a merge gate

Lighthouse scores are noisy on shared GitHub-hosted runners - variable CPU throttling and cold caches routinely swing performance and TBT numbers run to run. Gating merges on that would produce flaky red checks that block unrelated content PRs. So this is deliberately a report, not a gate:

• Every assertion is warn, so lhci exits 0 even on a budget miss.
• The lhci step is continue-on-error: true (belt-and-suspenders against Chrome launch flakiness).
• A regression surfaces as a job summary and a single tracking issue (label lighthouse), mirroring the single-issue pattern in link-rot.yml. It never fails the run.

Validation

• python3 -c "import json; json.load(open('lighthouserc.json'))" -> OK; YAML parsed OK (ruby).
• Only new files added; no other guard workflow is affected.
• Could not run Lighthouse locally (no Chrome installed in this environment) - validity is YAML/JSON parse plus config reasoning. First scheduled/dispatch run on the runner will exercise it end to end.