Prefetch low-res CT on card hover (viewer feels instant)

[aperson30]

What

Extends the existing hover warm-up on dataset cards. Today onMouseEnter warms the viewer JS chunk (prefetchViewer); this also warms the low-res CT after a short hover dwell, so clicking a card pays only decode + render instead of the download. This is the biggest perceived-latency win from the speed plan.

Volume responses are immutable (Cache-Control: max-age=604800, immutable), so a prefetched CT is reused straight from the browser cache on click.

Safety (shared JHU infra)

• CT only — never the mask (halves bandwidth)
• Dedupe — each case fetched at most once per session
• Global concurrency cap (2) — hovering across the grid can't stampede the backend. This cap is also why it's safe before the low-res batch finishes: worst case is a couple of full-res CTs in flight, not the whole grid.
• 150ms hover dwell — skimming across cards doesn't fire fetches; cleared on mouse-leave.

Files

• helpers/prefetchVolume.ts (new) — queued, capped, deduped low-res CT prefetcher
• components/Preview.tsx — dwell-timer on the card hover, cleared on leave

Testing

• tsc -b clean
• 101/101 frontend tests pass

Not included (deliberately) — #3 and #4 from the speed plan

Both rewrite the viewer's WebGL init/load path, which can't be validated locally (jsdom has no GPU; this checkout has no image data), so shipping them blind risks black-screening the viewer:

• increasing file upload size limit #3 drop the serial HEAD probe (VisualizationPage.tsx:350) — the local-vs-HF decision currently depends on the HEAD result; removing it needs a GET-error→HF fallback wired into the loader first.
• using chunked uploads to bypass vercel limit #4 progressive render (CT first, mask washes in) — needs the CT/seg loads split in renderVisualization.

Recommend doing those as a follow-up with testing against real data on the server.