Cache the wall of fame body with a daily key

[mroderick]

Caches the rendered wall of fame body (DashboardController#wall_of_fame, /coaches) in Solid Cache under a daily key. Closes #2974.

What changes

• The controller caches the rendered template body, without the layout, expiring after 24 hours. A cache hit costs one cache read plus a fresh layout render.
• The page param is coerced with pagy's own coercion before it enters the key, so arbitrary strings cannot expand the key space, and pagy links keep only the year and page params, so the first request to fill a key cannot freeze unrelated query params into the cached links.
• The layout renders on every request, so fingerprinted asset URLs and meta tags never go stale — the same body-without-layout approach the sponsors page took in Cache the rendered /sponsors page body — recurring 1.3s render stalls dyno threads #2885.

Measured impact

Benchmarks against master on the local production dump (production mode, Solid Cache, real data: 3,575 attended coaches), median of 5 warm requests:

Path	master	this branch	change
/coaches	0.097s, 5 queries, 13.9K allocs	0.014s, 0 queries, 4.5K allocs	−86% time, −68% allocs
/coaches?page=2	0.069s, 5 queries, 13.0K allocs	0.006s, 0 queries, 4.6K allocs	−91% time, −65% allocs
/coaches?year=2024	0.086s, 5 queries, 14.7K allocs	0.007s, 0 queries, 4.6K allocs	−92% time, −69% allocs

A cache miss costs the same as an uncached render plus two cache writes, and only the first request per key per day pays it. Applied to the drain figures in #2974 (42.7M GC allocations/week), the warm-hit reduction projects to roughly 28M allocations/week saved.

Staleness

The list changes only when a coach attends a workshop, so a 24-hour window is acceptable for this page. The controller comment documents that the key version (v2) must be bumped when the view or its partials change.

Only the current year's data changes with new attendance, so past-year keys drop the date segment and carry no explicit expiry: entries age out via Solid Cache's max_age (2 weeks by default) instead of rotating at midnight. On the production dump that leaves ~39 dated keys rotating daily and ~861 past-year keys (year × page × 3 locales) always warm. Profile edits on old coach cards propagate within that 2-week window rather than within 24 hours. Junk years keep the dated, expiring key so arbitrary requests cannot create immortal entries.

Reviewer notes

Focus on the cache key design and the staleness tradeoff:

• Key: coaches/wall_of_fame/v2/#{date}/#{year}/#{page}/#{locale} with expires_in: 24.hours; past years (2013..current−1) drop the date segment and expiry. The date segment means a New Year rollover rotates the current year's keys automatically.
• Coach cards for the current year can be up to 24 hours out of date; past years up to 2 weeks (Solid Cache max_age). If that proves too coarse, shorten the expiry — no key-format change needed.

Detail

• From the issue's production measurements: 3,411 requests/7 days, 42.7M GC allocations (~6% of controller churn), p95 14.1K allocations per request.
• The issue's sketch cached render_to_string including the layout; this PR deliberately renders the layout fresh instead. Caching fingerprinted asset URLs for 24 hours would serve stale asset links after a deploy, the reason Cache the rendered /sponsors page body — recurring 1.3s render stalls dyno threads #2885 cached only the partial.
• The cache key normalises page to the integer pagy will render, and strips everything but year and pagy's own page key from link URLs. A pre-existing, unrelated bug in page_year? (application_helper.rb:82, Integer-vs-String comparison, so the active year button never highlights) is out of scope here; fixing it will require a key-version bump since the button state is inside the cached body.