Redis-backed application cache for hot read paths

[ptrlrd]

Run uploads went from ~9k/week to ~130k/week. Every uncached read is amplifying Mongo load proportionally. PR #385 added a Mongo-backed lazy cache (stats_summary) which handles the worst-case "first user pays 5-10 s" path; this PR puts an even faster, configurable, cross-endpoint layer in front of it and the other hot reads.

What

A fail-safe Redis layer (services/cache.py) plus wiring into the four hottest read paths.

Cache substrate

• services/cache.py — lazy redis-py client, get_json / set_json / delete / delete_pattern (SCAN-based). Every operation is fail-safe: Redis being unavailable returns None on get and no-ops on set, so the caller falls back to its existing data source. The cache is always an optimization, never load-bearing.
• metrics.py — spire_codex_cache_hits_total / _misses_total / _errors_total, labeled by key namespace (stats, leaderboard, run, entity_scores).

Wired in

Endpoint	Layer 0	TTL	Why
/api/runs/stats	Redis check before stats_summary	60s	Matches refresher cycle; cluster-wide instead of per-worker
/api/runs/leaderboard	Redis check before leaderboard_summary	60s	Same reasoning; covers today / paginated combos that aren't in leaderboard_summary
/api/runs/shared/{hash}	Redis check before disk	15min	Runs are immutable, but I don't want every viewed run squatting in cache forever as the collection grows. 15min absorbs share-link bursts on a hot URL and lets cold runs drop off the LRU
/api/runs/scores/{entity_type}	Redis check before snapshot read	5min	Hit constantly by tier-list + detail-page sort columns

Infra

• redis:7-alpine service in docker-compose.yml (dev), docker-compose.beta.yml, docker-compose.prod.yml. allkeys-lru eviction, AOF off (rebuildable from Mongo on miss), maxmemory 512 MB in prod / 128 MB in beta+dev. Healthcheck in prod.
• REDIS_URL env var passed into the backend in each compose, with sensible defaults that point at the bundled redis service. When unset, every cache call no-ops -- the existing data paths run unchanged.
• redis==5.2.1 added to requirements.txt.

Operational story

• Redis down or unreachable → all reads miss, all writes no-op. Every endpoint still works, just at pre-PR latency. No 500s.
• Cache cold after restart / deploy → the existing Mongo materialization (stats_summary, leaderboard_summary, entity_stats_snapshot) is still warm, so first requests hit ~ms (Mongo find_one) rather than the live aggregation. Redis warms up naturally on traffic.
• Memory pressure → allkeys-lru evicts oldest keys; cap protects the host.

What this unlocks for the next PR

Adding a new cache target is app_cache.get_json(key) / app_cache.set_json(key, val, ttl_seconds=N) -- no additional infrastructure. Obvious next wins:

• /api/cards/*, /api/relics/*, /api/potions/* list responses (high QPS, deterministic per (entity, lang) between deploys; could go on a multi-hour TTL with a deploy-time delete_pattern).
• /api/auth/me (one Mongo find_one per request becomes one Redis GET; cookie-keyed).
• slowapi rate-limit storage so limits become cluster-wide and survive worker restarts (slowapi[redis] + a config line).

Compose deploy note

When this lands, the prod compose changes (Redis service + REDIS_URL passthrough) require a docker compose -f docker-compose.prod.yml up -d on the box to bring up the new spire-codex-redis container. The backend image alone won't pick up Redis until the compose is re-applied.