Eager-load host and chapter-organiser chains for event listings

[mroderick]

Summary

GET /events/upcoming rendered ~31 queries per request (production median 467ms). Three per-card query sources, all association hops the existing eager loads didn't cover:

1. WorkshopPresenter#venue → model.host → workshop_host.sponsor — the sponsor behind the has_one :host through-chain loaded one query per hosted workshop (13 on the measured page)
2. WorkshopPresenter#organisers falls back to the chapter's organiser members when a workshop has none; chapter.permissions.find_by(name: 'organiser') loaded one query per such card
3. latest_model_updated ran its four MAX queries twice — fresh_when received it as both the Last-Modified value and the etag

Changes

• The workshop eager load now covers workshop_host: :sponsor and chapter: { permissions: :members }
• chapter_organisers reads the loaded collections instead of find_by, which builds a new relation and bypasses the association cache
• latest_model_updated is computed once in upcoming and past

Measured

Against codebar_production_dump (fragment cache warm): 26 queries → 9, warm render ~115ms either way. Reproduced the production shape: the 13 single-sponsor queries and the double MAX queries are gone.

Review notes

• Riskiest part: the workshop query now joins chapters → permissions → members. Only members attached to a chapter's organiser permission join in, so row multiplication is bounded, but worth a look.
• chapter_organisers behaviour is unchanged for empty results (nil → [] in both shapes).
• ETag/Last-Modified values are identical, just computed once — cheapest to review.
• Deliberately not done: the chapter page has its own non-eager load path and still N+1s per fallback card (pre-existing); /events/past shares load_events but has no query-count guard of its own.

Verify

Query count drops in production (Scout APM: /events/upcoming); median duration drops with it; ETag behaviour unchanged.

Fixes #2888