Bound Charts hero auto-rotation asset loading

[tannerlinsley]

@tannerlinsley The new Charts landing hero continuously advances through the full published catalog while it remains visible. This needs a product/design choice before changing the behavior.

Evidence

• CatalogChartsHero starts one timer per visible tile at 2.7s, 3.0s, and 3.3s and advances each index modulo every catalog case.
• The current published catalog has 102 cases. On desktop, the three sequences collectively visit all 102 case IDs in about 109 seconds. On mobile, the single 2.7s sequence eventually visits all cases in about 273 seconds.
• Every case change remounts ChartsCatalogChart, which dynamically imports the case module and appends its declared modulepreload dependencies.
• In the current catalog-dist manifest (revision e08e12c6303c4393de7232a22f2b1669c9cc7feb), the three initial desktop cases reference 38 unique assets totaling 257,885 uncompressed bytes. The full TanStack case graph references 283 unique assets totaling 4,150,892 uncompressed bytes.
• Asset URLs are immutable and cache well, so this is primarily a first-visit cost. CDN/browser compression will reduce wire bytes, but an idle visitor can still trigger hundreds of progressive asset requests without asking to browse the catalog.

Relevant source:

• src/components/landing/ChartsCatalogGallery.tsx
• src/components/charts/ChartsCatalogChart.tsx

Expected impact

Bounding automatic rotation would reduce background network, parse, and mount work on the Charts landing page, especially for visitors who leave the hero visible. It also reduces repeated work in the same-origin catalog asset route on cold CDN misses.

Proposed direction

Use a small curated set for automatic hero rotation, or keep the initial three charts fixed and reserve chart changes for the existing user control. Continue deferring the full horizontal catalog until cards approach the viewport.

A focused regression test can assert that the automatic sequence is bounded and does not enumerate catalog.cases.

Alternatives and tradeoffs

1. Fixed initial three, user-controlled next — lowest background cost; loses ambient variety.
2. Rotate within a curated bounded set — preserves motion and variety; requires choosing representative cases.
3. Stop after one bounded pass — limits repeat work but can still download every case if the pass uses the full catalog.
4. Keep current behavior — maximizes catalog exposure but intentionally accepts progressive loading of the full 4.15 MB uncompressed asset graph.

Decision needed

Should automatic rotation be removed or constrained to a curated subset? If constrained, which examples should represent the hero?