Convert frontend signup consumers off deprecated bucket_key/requested_bucket_key

[nbudin]

Fixes #11899

Summary

Signup/SignupRequest/SignupRankedChoice/SignupChange/GroupedSignupCount all already have deprecation_reason-marked bucket_key/requested_bucket_key scalar fields with an id-carrying bucket/requested_bucket relation as the documented replacement — but the frontend never switched over. This PR does that switch across every remaining business-logic correlation point discovered while scoping #11895:

• SignupUtils.ts: findBucket/formatBucket/formatSignupStatus now correlate by id instead of key.
• SignupCountData.ts: flattens bucket?.id into a synthetic bucket_id at construction time (its generic filter mechanism compares plain field values, so it can't filter on a nested relation directly).
• AvailabilityUtils.tsx, buildSignupOptions.ts, RunCapacityGraphBucket.tsx, BucketInput.tsx, $id/route.tsx, RunSignupSummary.tsx, RunEmailList.tsx, RunSignupsTable.tsx, UserSignupQueueItem.tsx, SignupModerationQueue.tsx, BucketChangeCell.tsx: all switch their bucket lookups/filters from key to id.
• $id/change_bucket.tsx: derives its seed key from the bucket relation instead of the deprecated scalar, without changing BucketInput's key-based selection/submission mechanism (a separate concern — see below).
• Updated 8 .graphql query files to select bucket { id }/requested_bucket { id } instead of the deprecated scalars, including EventAdmin/queries.graphql's schedule-preview fragments (needed to keep the shared ScheduleEvent type consistent — not in the original file list, but a required consequence of the type change).

Deliberately out of scope

• BucketInput.tsx's actual selection value/onChange and the ChangeSignupBucket/ForceConfirmSignup mutations still use bucket key. Converting that would mean also touching change_bucket.tsx/force_confirm.tsx's mutation arguments — a distinct concern from "stop reading the deprecated field for comparison," so left alone here.
• BucketKeyRemappingModal.tsx/useBucketKeyRemapping.tsx and bucket_keys_with_pending_signups_or_requests — that feature is genuinely about renaming key strings, not a lookup identity, so it stays key-based by design.

Test plan

• yarn run tsc --noEmit
• yarn vitest run (187 passed, 1 pre-existing skip)
• yarn eslint on all changed files (0 errors)
• bin/rails test (1169 passed, 1 pre-existing skip) — no backend files changed, confirms no regressions from the frontend query changes
• Confirmed schema.graphql/schema.json have zero diff (no schema changes, purely frontend query/consumer changes)

Not done: a live manual walkthrough of the affected screens (signup admin single-signup view, run signups table/email list/summary, my signup queue, schedule grid, signup moderation queue, reports signup spy table) in a browser. This is a large, mechanical conversion covered thoroughly by TypeScript's structural typing (every changed data shape is checked against its actual GraphQL query result) and the existing test suite, but neither of those substitute for exercising the real UI. Worth a manual pass before merging, especially on the signup admin and moderation screens.

🤖 Generated with Claude Code

[github-actions]

Code Coverage Report: Only Changed Files listed

Package	Base Coverage	New Coverage	Difference
app/graphql/intercode_schema.rb	🟠 61.84%	🟠 55.26%	🔴 -6.58%
app/graphql/types/grouped_signup_count_type.rb	🟢 85%	🟢 80%	🔴 -5%
app/javascript/EventsApp/EventPage/buildSignupOptions.ts	🟢 87.5%	🟢 88.89%	🟢 1.39%
app/javascript/EventsApp/SignupCountData.ts	🟠 72.73%	🟠 73.91%	🟢 1.18%
Overall Coverage	🟢 56.04%	🟢 56.02%	🔴 -0.02%

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