Convert frontend signup consumers off deprecated bucket_key/requested_bucket_key scalar fields

[nbudin]

Background

While scoping #11895, research turned up a much larger, adjacent gap than that issue's own scope: across nearly the entire signup/moderation/schedule frontend, Signup/SignupRequest/SignupRankedChoice/SignupChange/GroupedSignupCount are all queried using their deprecated bucket_key/requested_bucket_key scalar fields, even though every one of those types has already been given an id-carrying bucket/requested_bucket object relation as the documented replacement (deprecation_reason: "Use bucket instead" / "Use requestedBucket instead" is already present on all of them -- this is not a missing backend field, it's a frontend migration that hasn't happened yet).

This is a distinct problem from #11895 (which is about RegistrationPolicyBucket#key, the bucket's own identity field) and from #11896's currently-described scope (which assumes the frontend has already stopped reading these deprecated fields). It needs to happen before #11896 can actually remove bucketKey/requestedBucketKey from SignupType/SignupRequestType/SignupRankedChoiceType/SignupChangeType/GroupedSignupCountType -- right now this codebase's own frontend is the reason those fields can't be deleted yet.

Concretely, as of this research:

GraphQL query files still selecting the deprecated scalar fields (need bucket { id ... } / requested_bucket { id ... } selected instead):

• app/javascript/queries.graphql (RunBasicSignupData, if it selects grouped_signup_counts)
• app/javascript/EventsApp/EventPage/queries.graphql (MySignupRequestFields, MySignupRankedChoiceFields, EventPageRunFields.grouped_signup_counts)
• app/javascript/EventsApp/ScheduleGrid/queries.graphql
• app/javascript/EventsApp/SignupAdmin/queries.graphql (SignupFields, UserConProfileSignupsFragment, RunSignupsTableSignupsQuery, RunSignupSummaryQuery, RunSignupChangesQuery incl. previous_signup_change)
• app/javascript/SignupModeration/queries.graphql (SignupModerationRunFields.grouped_signup_counts, SignupModerationSignupRequestFields)
• app/javascript/Reports/queries.graphql (SignupSpySignupChangesQuery incl. previous_signup_change)
• app/javascript/EventsApp/MySignupQueue/queries.graphql (UserConProfileRankedChoiceQueueFields.signup_ranked_choices)

Frontend consumers whose logic needs to switch from string-key comparison to id comparison:

• app/javascript/EventsApp/SignupAdmin/SignupUtils.ts (findBucket/formatBucket -- the most widely-used correlation point in the whole signup UI)
• app/javascript/EventsApp/SignupCountData.ts (its entire generic filter mechanism is keyed by bucket_key/requested_bucket_key today; needs to flatten bucket?.id/requested_bucket?.id at construction time so sumSignupCounts can filter by id)
• app/javascript/EventsApp/SignupAdmin/BucketInput.tsx
• app/javascript/EventsApp/SignupAdmin/$id/route.tsx (the bucket/requestedBucket lookups at the top of the file -- not the same as the single already-fixed comparison line from Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895)
• app/javascript/EventsApp/SignupAdmin/RunSignupsTable.tsx
• app/javascript/EventsApp/SignupAdmin/RunEmailList.tsx (the includes/includesObject correlation -- not the display-fallback line already fixed by Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895)
• app/javascript/EventsApp/SignupAdmin/RunSignupSummary.tsx
• app/javascript/EventsApp/ScheduleGrid/AvailabilityUtils.tsx
• app/javascript/EventsApp/EventPage/buildSignupOptions.ts (the grouped_signup_counts and ranked-choice correlations -- not the SignupOption.key line already fixed by Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895)
• app/javascript/EventsApp/EventPage/RunCapacityGraphBucket.tsx
• app/javascript/EventsApp/MySignupQueue/UserSignupQueueItem.tsx
• app/javascript/SignupModeration/SignupModerationQueue.tsx
• app/javascript/Tables/BucketChangeCell.tsx

Proposed Change

1. Update each GraphQL query file above to select bucket { id } / requested_bucket { id } (plus whatever else each call site needs, e.g. name) alongside or instead of the deprecated scalar fields.
2. Rework SignupUtils.ts's findBucket/formatBucket to correlate by id.
3. Rework SignupCountData.ts to flatten bucket_id/requested_bucket_id at construction time and filter by those instead of bucket_key/requested_bucket_key.
4. Update every consumer listed above accordingly.
5. Run bin/rails graphql:update to regenerate the frontend generated files.
6. Once this lands (and Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895's editor fix has been running long enough that live edits reliably carry bucket ids), re-verify Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896's field list is actually safe to deprecate/remove -- some of it already is deprecated; this issue is what makes removal (not just deprecation) safe.

Benefits

• Removes this codebase's own frontend as a blocker to Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896 actually deleting bucketKey/requestedBucketKey from the schema, rather than just leaving them deprecated indefinitely.
• Consistent id-based correlation across the whole signup UI, instead of a mix of id-based (registration policy bucket editing, per Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895) and key-based (everything reading a Signup's own bucket) approaches.

Tradeoffs

• Large surface area (~7 GraphQL query files, ~13 consumer files) touching nearly every signup-admin/signup-moderation/event-page/schedule-grid screen in the app. Recommend doing this as its own reviewed PR rather than folding it into Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895, and possibly splitting further (e.g. SignupUtils.ts/SignupCountData.ts first, since almost everything else depends on them).
• SignupCountData.ts's filter mechanism is currently generic over any field of GroupedSignupCount; switching to id-based bucket filtering means flattening a nested bucket/requested_bucket object into synthetic top-level fields at construction time, which is a real (if small) design decision, not a pure rename.

References

• Parent: Convert bucket_key/requested_bucket_key to real foreign keys #11868
• Discovered while scoping: Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895
• Prerequisite for actually removing (not just deprecating) the fields listed in: Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896

---

Issue drafted by Claude