Retire RegistrationPolicyBucket#key as an identity mechanism in the app layer

[nbudin]

Fixes #11897

Summary

• RegistrationPolicy#sync_buckets_from_hash!/#match_existing_bucket: removed the existing_by_key fallback. A bucket hash with no id is now unambiguously "create a new row" — never "maybe this secretly matches something by key."
• RegistrationPolicy#equivalent_to?: switched from key-based to id-based bucket matching. A bucket with no id always counts as "different" (correct — a brand-new bucket, by definition, changes the policy).
• EventChangeRegistrationPolicyService::SignupSimulator#candidate_bucket_for: switched to an id-based lookup, matching the same reasoning.
• RegistrationPolicyBucket#occupies_bucket_as_signup?: reviewed per the issue, but needs no change — it's already id/object-identity based, never key-based.

Caller audit (per the issue's request, before removing the fallback)

• update_event_proposal.rb — goes through the exact same generic, already-id-threaded registration policy editor as update_event.rb (Give the registration policy editor real bucket ids (phase 1 of dropping RegistrationPolicyBucket#key) #11895), since both Events and EventProposals use the same registration_policy form-item type. No separate frontend fix needed.
• accept_event_proposal_service.rb, create_event.rb, create_filler_event.rb, create_event_proposal.rb — none call update_from!/sync_buckets_from_hash! against a pre-existing policy (they either build a policy for a brand-new record, or use build_from_hash_as_clone, which never syncs against the source). Unaffected.
• import_convention_data_service.rb — confirmed always a brand-new Convention, per the issue.

Test fallout

This surfaced a real gap in the test suite: several tests built a new_registration_policy fixture via key-only hashes (no ids) to describe "editing an existing bucket," implicitly relying on the fallback being removed. Fixed by:

• Adding build_edited_registration_policy to test_helper.rb, which supplies the real id for any bucket spec whose key matches an existing bucket — mirroring what the frontend editor now actually sends.
• Adding assert_registration_policies_have_equivalent_buckets, since equivalent_to? can no longer verify "these two independently-persisted/detached policies describe the same buckets" (e.g. a clone against its source, or a freshly-persisted policy against the detached hash that requested it) now that it matches by id instead of content. Several existing tests needed this key-based comparison instead — genuinely different use cases than what equivalent_to? is designed for post-Retire RegistrationPolicyBucket#key as an identity mechanism in the app layer (phase 3 of dropping RegistrationPolicyBucket#key) #11897.
• Rewrote one test whose entire premise was the now-removed key-fallback (sync_buckets_from_hash! "preserves row id... falls back to key-matching without an id") to assert the opposite, correct behavior.

Test plan

• bundle exec rubocop on all changed files (0 offenses)
• bin/rails test (1169 passed, 1 pre-existing skip)

🤖 Generated with Claude Code

[github-actions]

Code Coverage Report: Only Changed Files listed

Package	Base Coverage	New Coverage	Difference
app/models/registration_policy.rb	🟢 98.73%	🟢 98.7%	🔴 -0.03%
app/models/registration_policy_bucket.rb	🟢 98.08%	🟢 96.15%	🔴 -1.93%
Overall Coverage	🟢 56.04%	🟢 56.04%	⚪ 0%

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