perf(worker): cache the public summary per colo and read D1 one query fewer

[cgaravitoq]

What

The summary route advertised Cache-Control: public, s-maxage=300, but a Worker on a Custom Domain runs in front of the edge cache, so nothing was ever cached. Measured on 2026-10-08:

• About 6,000 summary requests a day, nearly all from the portfolio's server render.
• 54% of them ended in 499, because that caller gives up at 500 ms from BOM, ICN, NRT, HKG, LAX and SEA.
• About 4,500 SELECT ... GROUP BY executions a day in wrangler d1 insights.
• Each summary made three sequential round trips to D1 in WEUR.

Change

• summarizeUsage reads the user and the timezone of its most recently seen machine in one LEFT JOIN, keeping the same last_seen, machine_id tie-break and the UTC default. A summary now costs two round trips instead of three.
• cachedSummary in src/server/summary-cache.ts keeps a summary in the Cache API per colo for the five minutes the route already advertises. It keys by the lowercased login and the range, and never caches a login without an account. The route uses it, and the landing page can call it instead of summarizeUsage.
• The portfolio gets its own per-colo stale-while-revalidate cache in a separate PR (cgaravitoq/portfolio-monorepo), which removes most of the traffic. This PR makes the remaining misses and the public widget cheap.

Verification

• New specs: summary-cache.spec.ts covers a repeated summary served without touching D1, one key per lowercased login and range at max-age=300, and no entry for an unknown login. A usage.spec.ts case asserts two prepare calls per summary.
• The app and catch-all specs stub caches.open with an in-memory cache through src/test/memory-cache.ts.
• format, lint:slop, check-types, test, test:dependency-policy, test:package, audit:production, build and wrangler deploy --dry-run all pass locally.