perf: EventCardComponent + Solid Cache for event listings

[mroderick]

What

Makes /events/upcoming and /events/past render faster by extracting a shared EventCardComponent, adding fragment caching with Solid Cache, and removing user-specific badges from public listings.

Why

The /events/past page was timing out on Heroku (503). PR #2682 restored UNION ALL database-level pagination, reducing load from ~11s to ~1.3s. This PR adds view-level caching and component consolidation on top of that foundation.

Changes

• Solid Cache — database-backed cache store on the existing Postgres connection (no extra Heroku cost). Configured with a 500 MB cap.
• EventCardComponent — single ERB component replaces three HAML partials (events/_event, workshops/_workshop, meetings/_meeting). Templates compile to Ruby methods, avoiding HAML parsing overhead.
• Fragment caching — individual event cards cached via cache @event.cache_key_with_version. Auto-invalidates on model updates.
• User badges moved — "Attending" and "Manage" badges removed from public listings, shown only on dashboard (where user context is explicit). This makes listings fully cacheable.
• Benchmark script — script/benchmark_events.rb for measuring against codebar_dump.

Benchmark results (codebar_dump)

Page	Before (master)	After
/events/past cold	1.5s / 139 queries	0.10s / 12 queries
/events/past warm	1.5s / 139 queries	0.10s / 12 queries
/events/upcoming cold	12.2s / 178 queries	0.18s / 12 queries

Deployment note

solid_cache_entries table needs creating in production databases. Run:

rails db:migrate
# or
rails db:prepare

The table schema is in db/cache_schema.rb.

Clean history

3 commits:

1. deps: add solid_cache for fragment caching
2. chore: add benchmark script for event listing performance
3. feat: add EventCardComponent with fragment caching

[mroderick]

I've tested this on staging, where it performs well.