Retry notes dual sharding key repair trigger migration

What does this MR do and why?

The AddRepairDualShardingKeyTriggerToNotes post-deployment migration (20260902151429, introduced in !250291 (merged)) exhausted all lock-retry attempts on gprd because of lock contention with an ongoing autovacuum on the notes table. A confirmed-safe retry failed the same way, so the migration was manually marked as executed to unblock the deployment pipeline. As a result, gprd currently lacks the repair_dual_sharding_key_on_notes function and the trigger_817aa51bc4f2 BEFORE UPDATE trigger, which must exist before the strict sharding-key constraint in !253560 can proceed.

This MR follows the established pattern for retrying a failed migration (for example, RetryRemoveFkWebHookLogsDailyProjectId):

1. No-ops the original 20260902151429_add_repair_dual_sharding_key_trigger_to_notes migration, since migration files are immutable once merged and we do not backdate migrations.
2. Adds 20260908184215_retry_add_repair_dual_sharding_key_trigger_to_notes, which creates the identical trigger and function. The replacement is idempotent (CREATE OR REPLACE FUNCTION, DROP TRIGGER IF EXISTS before re-creating the trigger), so it is safe on environments where the original migration succeeded (staging, development, self-managed).

Remaining production rollout (not part of this MR)

Merging this MR does not change gprd by itself; the post-deployment migration still needs controlled execution there. To complete the corrective action:

1. Schedule a Change Request for a window with low autovacuum activity on notes (per the originating work item).
2. Confirm via Rails migration status that 20260908184215 runs to completion on gprd without lock-wait timeouts.
3. Verify repair_dual_sharding_key_on_notes and trigger_817aa51bc4f2 are present in the production schema, then close the work item.

References

• Corrective action work item: #627843 (closed)
• Original trigger MR (merged): !250291 (merged)
• Main dual-sharding-key issue: #601451
• UPDATE safety issue: #614281 (closed)
• Strict constraint MR (open): !253560

Screenshots or screen recordings

Not applicable: database migration only, no UI changes.

How to set up and validate locally

1. Run the migration spec:

   bundle exec rspec spec/migrations/20260908184215_retry_add_repair_dual_sharding_key_trigger_to_notes_spec.rb

2. Or run bundle exec rails db:migrate and confirm in psql that repair_dual_sharding_key_on_notes() and trigger_817aa51bc4f2 exist; updating a notes row that has both namespace_id and project_id set must null out namespace_id.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.