Fix N+1 query on registration_policy/buckets in SignupCountPresenter

[nbudin]

Summary

Sentry surfaced a cluster of N+1 queries after #11871/#11872 shipped (INTERCODE-176/178/17C/179/17D/17B/17E), all showing the same repeated pair, 33-100 times per request:

SELECT "registration_policies".* FROM "registration_policies" WHERE "registration_policies"."id" = $1 LIMIT $2
SELECT "registration_policy_buckets".* FROM "registration_policy_buckets" WHERE "registration_policy_buckets"."registration_policy_id" = $1 ORDER BY "registration_policy_buckets"."position" ASC

across page-load queries (AppRootLayoutQuery/CmsPageQuery, rendered via CMS Liquid tags), Convention.event_categories, and signup mutations.

Root cause

SignupCountPresenter.for_runs(runs) batches the signup-count SQL across all runs in one query, but constructs a SignupCountPresenter per run without preloading run.event.registration_policy.buckets first. Each presenter's #registration_policy/#buckets then hits that association fresh — once per run. RunAvailabilityPresenter.for_runs wraps SignupCountPresenter.for_runs and has the same exposure through its own #registration_policy/#buckets delegation, so it inherits the fix for free once the underlying batch is preloaded.

This is a sibling gap to the N+1 #11869 already fixed: that PR wired registration_policy/buckets into the GraphQL dataloader (association_loaders) for EventType/EventProposalType/RegistrationPolicyType, but SignupCountPresenter/RunAvailabilityPresenter (used by CMS Liquid drops and the Sources::SignupCount dataloader source) never got the same treatment.

Fix

SignupCountPresenter.for_runs now preloads event: { registration_policy: :buckets } across the full batch of runs before constructing any presenters, via ActiveRecord::Associations::Preloader (the same primitive the GraphQL dataloader's Sources::ActiveRecordAssociation uses). This fixes all callers that go through .for_runs: RunAvailabilityPresenter.for_runs (CMS run_availabilities/runs_with_openings Liquid tags) and the Sources::SignupCount GraphQL dataloader source (RunType#confirmed_limited_signup_count, #grouped_signup_counts).

Added a regression test (verified it fails without the fix — 20 queries for 10 runs — and passes with it, ≤2 queries regardless of run count).

Out of scope

Sentry also showed a smaller, lower-volume version of the same query pair in Mutation.createSignupRequest and sibling mutations (createMySignup, createUserSignup, updateSignupBucket, forceConfirmSignup, createSignupRequest) -- 4-11 occurrences per event vs. 33-100 for the page-load path above. I wasn't able to pin down a concrete root cause for that one (the registration_policy/buckets association should already be memoized within a single mutation call), so I'm leaving it for a follow-up rather than guessing at a fix.

Test plan

• test/presenters/signup_count_presenter_test.rb (new N+1 regression test + full existing suite)
• test/liquid_drops/convention_drop_test.rb, test/models/run_test.rb
• Broader registration-policy/signup service suite (126 tests)
• rubocop / stree clean

🤖 Generated with Claude Code

[github-actions]

Code Coverage Report: Only Changed Files listed

Package	Base Coverage	New Coverage	Difference
app/presenters/signup_count_presenter.rb	🟢 91.07%	🟢 91.23%	🟢 0.16%
Overall Coverage	🟢 55.88%	🟢 55.91%	🟢 0.03%

Minimum allowed coverage is 0%, this run produced 55.91%