fix(docs): wire the savings leaderboard's Supabase anon key into the docs build

[jonsaadfalcon]

Problem

The docs-site savings leaderboard (docs/javascripts/leaderboard.js) reads the public Supabase anon key from window.OPENJARVIS_SUPABASE_ANON_KEY, but nothing ever set that global. So the published leaderboard always shows "Leaderboard not configured yet." This is the docs half of the leaderboard wiring — the PyPI/desktop builds get the key via the VITE_SUPABASE_ANON_KEY build var (#588/#589), but the mkdocs site uses a separate window.* mechanism that was never connected.

Fix

Inject the key at docs-build time, mirroring the build-var approach:

• docs/javascripts/leaderboard-config.js (new) — declares window.OPENJARVIS_SUPABASE_ANON_KEY, empty by default.
• mkdocs.yml — load leaderboard-config.js before leaderboard.js so the global is set before it's read.
• .github/workflows/docs.yml — before mkdocs build, regenerate the config file from the existing VITE_SUPABASE_ANON_KEY secret. The secret is read via env: (not inlined) and JSON-encoded into a JS string literal, so there's no injection surface.
• tests/deployment/test_docs_leaderboard.py (new) — guards the load order and that the workflow injects the key.

The committed default is empty, so local mkdocs build and fork PRs (which have no secret) keep rendering the graceful "not configured" message. The anon key is public by design — Supabase Row-Level Security protects the data — so shipping it in the public docs bundle is expected.

Verification

• Local mkdocs build with a simulated injected key: site/javascripts/leaderboard-config.js ships with the value, and the built HTML loads leaderboard-config.js before leaderboard.js.
• The Supabase backend + an anon key were confirmed working separately (a direct GET /rest/v1/savings_entries returned live rows), so once this deploys, the docs leaderboard will populate.
• tests/deployment/ — 25 passed (4 new); ruff clean.

🤖 Generated with Claude Code