Speed up /coaches: partial index and database-side coach count

[mroderick]

Closes #2886

Summary

The /coaches page counted all-time attended coaches by loading the grouped result into Ruby (Relation#length materialises all 3,572 grouped rows) and aggregating over all 1.98M workshop_invitations rows — the slowest of the page's five queries. This PR:

• adds a partial index on workshop_invitations(member_id) WHERE attended AND role = 'Coach' (CREATE INDEX CONCURRENTLY), making the aggregation an index-only scan over the 18k matching rows, and
• replaces top_coach_query.length with COUNT(DISTINCT member_id) so the count never leaves the database as rows.

Measured (production dump, in-process, warm medians)

	before	after
page db_runtime	112ms	46ms
all-time coach aggregation	78.6ms (parallel seq scan)	3.3ms (index-only scan)
count query	—	1.6ms

Production context: post-#2889 the page sits at ~320-375ms total, db 252-344ms; this addresses most of what remains.

Trade-off

The index predicate must keep matching the to_coaches/attended scopes; if either scope changes, the index silently stops covering the count. A staging EXPLAIN after deploy is recommended. The index adds a small write cost to coach-attended rows (negligible at this table's write rate).

Verification

• spec/features/listing_coaches_spec.rb: new scenario pins the header count (same coach at two workshops counts once); 4/4 green.
• Migration round-trips on the test DB (db:rollback/db:migrate), including the concurrent drop.
• EXPLAIN on codebar_production_dump confirms the index-only scan.
• ce-code-review (5 reviewers): verdict "Ready to merge"; the single finding (concurrent rollback drop) applied in the second commit.