Fix stale deployment caches

[seveibar]

Summary

• namespace KV cache keys by the Cloudflare Worker deployment ID so each deploy starts with logically fresh entries
• stop browsers and shared caches from retaining HTML/JSON responses; requests now revalidate through the Worker
• reduce internal KV freshness from 14 days to 5 minutes and retention from 30 days to 1 day
• synchronously refresh expired entries and return refreshed data; use stale data only when D1 refresh fails
• expose x-cache-version alongside the existing cache diagnostics

Root cause

The Worker marked query results fresh for 14 days and sent the same two-week max-age to browsers. A deployed route or filtering change could therefore be hidden by both browser caching and an older KV response. The existing cachebust=1 escape hatch worked, but users should not need it after every deployment.

Live verification before this patch

The merged photodiode band filters are working in production:

/photo_diodes/list.json?wavelength=355&peak_distance_max=100&excluded_peak_bands=700-1100

The live response returned nine 420 nm-peak devices, excluded the 700–1100 nm peak band, and reported x-cache: MISS; the same query with cachebust=1 reported x-cache: BUST. Production also confirmed the problematic two-week cache-control header.

Validation

• bun test — 184 passed
• bunx tsc --noEmit
• bunx tsc --noEmit --project cf-proxy/tsconfig.json
• bun run format:check
• bunx wrangler deploy --dry-run --outdir /tmp/jlcsearch-cache-dry-run — version metadata binding recognized