SponsorsController#index still slow in production after #2803 caching (median 1.5s, render-bound)

Summary

Requests to /sponsors are chronically slow despite the fragment caching and table indexes merged in #2803. Measured from the canonical Rails logs (rails_semantic_logger process_action payload, collected via the production log drain) over a 3-hour window on 2026-09-16/17.

Measured (3h window, 123 requests)

The page is render-bound: 41ms of DB work across 5 queries, but 1.3s of view time. Fragment caching from #2803 does not appear to be effective in production.

Context

#2803 (merged 2026-08-31) split the sponsors partial for collection caching and added indexes. Local profiling at the time showed warm-cache partial allocations dropping ~80% (225k → 44k objects). Production medians are unchanged a month later.

Hypotheses

1. Fragment cache misses in production — cache store may be unset or per-dyno memory store, flushed by restarts
2. Cache key churn (sponsor updated_at touches) defeating reuse
3. Render cost outside the cached fragments (page shell, other partials)

Next steps

• Confirm the production cache store and measure the fragment hit rate
• Reproduce with a production-sized sponsor list and profile allocations again
• Decide on a caching strategy (longer-lived fragments, low-level caching, or both)

Start at SponsorsController#index and the caching changes from #2803. Confirm the production cache store and fragment hit rate, then reproduce the issue with a production-sized sponsor list while profiling allocations. Done means identifying whether cache configuration, key churn, or uncached rendering dominates and deciding on a caching strategy.