perf: cache the Sourcify / OpenChain / b32 proxy responses

[Agilulfo1820]

Why

The decoding pipeline introduced in #594 has every /api/sourcify, /api/openchain, and /api/b32 call pass straight through to the upstream. TanStack Query's staleTime: Infinity on the client only helps within one browser session; the routes set no cache headers and don't wrap their upstream fetch() in next: { revalidate }. With ~14 req/s headroom on Sourcify's free tier, our single App Runner egress IP is one busy preview env away from being throttled in production.

This PR adds a thin caching layer to the three proxy routes. Stacked on top of #594 — merge target is feat/decoding-pipeline, not main.

What

For each route:

1. Wrap the upstream fetch in next: { revalidate, tags } so repeats inside the TTL are served from Next's data cache (.next/cache/fetch-cache under output: 'standalone'). No external CDN required. Tagged so a future maintenance route can revalidateTag() without redeploying.
2. Set Cache-Control on the JSON response so browsers and any future CDN cache too.

TTLs differ by upstream stability:

Route	next: { revalidate } (200)	Response 200 Cache-Control	404 Cache-Control
/api/sourcify	7d	s-maxage=604800, stale-while-revalidate=2592000, max-age=86400	s-maxage=1800, stale-while-revalidate=86400, max-age=300
/api/openchain	7d	same as Sourcify when every hash hit; partial / miss uses the short 30m / 1d SWR window	same
/api/b32	1d	s-maxage=86400, stale-while-revalidate=604800, max-age=3600	same

Rationale for the split:

• Sourcify — a contract's ABI is tied to a one-shot verification at an address. Once verified, the ABI is effectively immutable. Long TTL is safe.
• OpenChain — hash → canonical signature is a cryptographic fact; the DB only grows. 200s can be cached for a week. The route now switches between "all hit" and "partial" Cache-Control depending on whether every requested hash resolved, so a newly indexed selector / topic surfaces inside 30 min instead of being stuck as a "no match" for a week.
• b32 — community-curated GitHub repo where entries get added and occasionally corrected. 1-day TTL keeps corrections from being stuck for a week.

5xx / timeout / network errors return Cache-Control: no-store so an upstream blip can't poison the cache.

/api/b32 also switches from apiClient.get (which doesn't forward next options) to a direct fetch, matching the pattern in the other two routes.

Known limitation — deploy / restart

Next's data cache lives in the container filesystem under .next/cache/fetch-cache and is wiped on every deploy and instance restart / scale-up. With 1–10 App Runner pods (per prod.yaml), the worst-case cold burst is pods × unique-contracts hit in the warming minute. Sourcify's ~14 req/s should absorb this; the durable fix is a persistent custom cacheHandler (Redis / Memcached / S3) — flagged as future work.

Test plan

• pnpm ts-check && pnpm lint && pnpm knip && pnpm test (223 pass)
• Local smoke (pnpm dev): all three routes return the expected Cache-Control header (verified via curl -sI against 0x5ef79995…, 0x095ea7b3, 0x4a25d94a).
• PR preview smoke: hit /api/sourcify?chainId=100009&address=0x5ef79995… twice via curl, confirm the second response is markedly faster and carries the 7d header.
• Browser smoke on the preview env: open the same VeBetterDAO tx twice; second visit should serve /api/sourcify from disk cache / 304, no upstream Sourcify fire visible in dev-server log.
• Force a 404 path (random unverified address); verify the response carries the short 30-min s-maxage.

🤖 Generated with Claude Code

[daithihearn]

Closing this as it was implemented in a different PR