Drop the registration_policy_buckets.key column (phase 4 of dropping RegistrationPolicyBucket#key)

[nbudin]

Background

#11895, #11896, and #11897 remove every remaining external and internal dependency on registration_policy_buckets.key being a real, persisted, unique database column. This issue is the actual column drop.

What's left needing a non-persisted key after the first three phases:

• RegistrationPolicy#build_from_hash/RegistrationPolicyBucket.new(key: ...): constructing an in-memory bucket from a hash (frontend edit payload, or import_convention_data_service.rb's import file) still wants to accept a key: attribute.
• EventChangeRegistrationPolicyService's bucket_key_mappings argument (to_key side only, per Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896): still needs some string handle for "map this removed bucket onto a bucket being created in this same edit," since that bucket has no id until persisted.
• import_convention_data_service.rb: bucket_key/requested_bucket_key remain the field names in the (externally-authored, staff-only) import file format, used purely to cross-reference a bucket and the signups that reference it within one import payload -- confirmed in earlier research to never need to match against pre-existing DB rows.

None of these need key to survive a database round-trip -- only to exist as an in-memory value for the duration of one request/import.

Proposed Change

1. Migration: drop idx_on_registration_policy_id_key_b71cb40026 (the unique index on (registration_policy_id, key)), then drop the key column and its NOT NULL constraint from registration_policy_buckets.
2. RegistrationPolicyBucket (app/models/registration_policy_bucket.rb): remove self.normalize_key's use as a column normalizer tied to an AR attribute, key='s super(...) override, and RegistrationPolicy#validate_bucket_key_uniqueness. Re-add key as a plain, non-persisted attr_accessor (still normalized on assignment, so build_from_hash/import/bucket_key_mappings continue working exactly as before) -- just never written to or read from the database.
3. Update RegistrationPolicyBucket#metadata/#as_json if they still reference key (they do, for audit-shape reasons per Convert remaining registration policy bucket key dependencies (SignupBucketFinder, EventChangeRegistrationPolicyService) to id #11892's comments) -- decide whether an in-memory-only key should still appear in serialized output, given it's no longer a stable, durable value once the bucket is reloaded from the database. Likely answer: drop "key" from as_json's output going forward (existing historical FormResponseChange records are unaffected either way, since they're immutable snapshots).
4. Regenerate the # == Schema Information annotate comments on RegistrationPolicyBucket and anywhere else that references this table.
5. Delete the now-fully-obsolete check_bucket_fk_backfill.rb script sitting untracked in the repo root, if it hasn't been cleaned up already (it verified the signup-side bucket_id/requested_bucket_id backfill from Convert bucket_key/requested_bucket_key to real foreign keys #11871/Drop legacy bucket_key/requested_bucket_key columns after #11871 backfill is verified in production #11872, which is unrelated to this column but was left over from that work).

Benefits

• Completes the elimination of RegistrationPolicyBucket#key as a durable, admin-facing concept, closing out the work started in Convert bucket_key/requested_bucket_key to real foreign keys #11868.
• Removes a NOT NULL + unique-indexed column and its associated validation/normalization code with no remaining behavioral purpose.

Tradeoffs

• Irreversible without a data-loss-accepting rollback (the column's historical values, once dropped, are gone -- though nothing in the app is confirmed to still need them after Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895-Retire RegistrationPolicyBucket#key as an identity mechanism in the app layer (phase 3 of dropping RegistrationPolicyBucket#key) #11897 land). Recommend confirming in a review/staging pass that no external tooling or admin habit depends on reading a bucket's key via the GraphQL API or CSV export before merging.
• Depends on Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895, Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896, and Retire RegistrationPolicyBucket#key as an identity mechanism in the app layer (phase 3 of dropping RegistrationPolicyBucket#key) #11897 having actually landed and been running in production for a while, not just merged -- this is the one step in the whole plan that can't be easily undone.

References

• Parent: Convert bucket_key/requested_bucket_key to real foreign keys #11868
• Depends on: Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895, Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896, Retire RegistrationPolicyBucket#key as an identity mechanism in the app layer (phase 3 of dropping RegistrationPolicyBucket#key) #11897
• Part of a 4-phase plan to eventually drop registration_policy_buckets.key; see Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895, Deprecate and remove the remaining bucket key-based GraphQL/Liquid surface (phase 2 of dropping RegistrationPolicyBucket#key) #11896, Retire RegistrationPolicyBucket#key as an identity mechanism in the app layer (phase 3 of dropping RegistrationPolicyBucket#key) #11897

---

Issue drafted by Claude

[nbudin]

Filed #11904 as a prerequisite: the registration policy editor currently indexes its in-progress edit state by key internally (unrelated to the id-based persistence matching #11895-#11897 fixed). This issue's plan to drop key from RegistrationPolicyBucket#as_json's output would break that, since the editor would receive existing buckets with no key at all. #11904 needs to land first.

Comment written by Claude