Fix top vault listing cache versioning

[miohtama]

Why

A transient mismatch was reported where the vault listing showed a stale 1M annualised return for the Peter Schiff vault while the detail page showed the refreshed negative return. Production data later converged, which points to stale listing/cache data rather than a return formatter bug.

The risky paths were the separate compressed /top-vaults/all-data payload cache and the browser in-memory listing cache. Either could keep an older listing payload around after SSR layout/detail data had moved to a newer top-vault dataset.

Lessons learnt

Use the dataset generated_at value as an in-app payload freshness check, not as a query-string cache key. Cloudflare R2 may strip query parameters from the underlying export path, so URL timestamp cache busting is not a reliable correctness mechanism here.

Avoid forcing HTTP revalidation on every listing request. Use a short HTTP freshness window and let the client do an explicit reload only when the returned payload timestamp is provably older than the SSR layout data.

Summary

• Keep /top-vaults/all-data URLs stable; no timestamp or generated-at query parameters are added.
• Version the in-process compressed /top-vaults/all-data payload cache by generated_at.
• Change /top-vaults/all-data to Cache-Control: public, max-age=300, stale-while-revalidate=300 to avoid checking the server on every listing request.
• Add diagnostic response headers for listing dataset version and compressed-cache age.
• Pass layout generatedAt into vault listing/chart client cache calls, then compare it against the payload generated_at timestamp.
• Retry the listing fetch with fetch(..., { cache: 'reload' }) if the returned payload is older than the layout dataset version.
• Prevent older in-flight responses from overwriting or being returned over newer cached vault data.
• Add focused client-cache tests for same-version reuse, newer-version refetch, stale-response retry, and out-of-order in-flight responses.