fix(migrations): drop CONCURRENTLY from 0201 indexes (#830)

## Summary
- Switches `0201_backfill_missing_reward_disbursements.sql` from `CREATE
INDEX CONCURRENTLY` to plain `CREATE INDEX` inside the migration's
`BEGIN/COMMIT`.
- Both indexes (`sol_reward_disbursements (challenge_id, specifier)` and
`sol_claimable_accounts (ethereum_address, mint, slot DESC)`) are now
atomic with the backfill INSERT — if anything fails, the schema rolls
back cleanly.

## Why
`CREATE INDEX CONCURRENTLY` waits on a `virtualxid` lock for every
transaction open during its build phases — not just transactions that
touch the target table, but every one in the cluster.

The legacy Python `index_rewards_manager` Celery task on
discovery-provider keeps ~3-minute transactions open against
`challenge_disbursements` continuously. As fast as one ends, another is
already open. So the CONCURRENTLY build can wait indefinitely without
ever seeing a quiet moment — and it did, for 10+ minutes blocked on
`Lock/virtualxid` in tonight's deploy.

Trade-off accepted: regular `CREATE INDEX` takes a `ShareLock` on the
target table for the duration of the build, blocking writes. But both
target tables are written only by the Go indexer, and only on
reward_manager `EvaluateAttestations` and claimable token `Create`
instructions — sparse on-chain. At current row counts each build
completes in seconds; the blocked writes just queue on pgxpool and
resume right after.

## Test plan
- [ ] Cancel any in-flight 0201 attempt and drop any invalid index it
left behind:
      ```sql
      SELECT pg_cancel_backend(pid) FROM pg_stat_activity
       WHERE query ILIKE 'CREATE INDEX CONCURRENTLY%';
DROP INDEX IF EXISTS sol_reward_disbursements_challenge_specifier_idx;
      DROP INDEX IF EXISTS sol_claimable_accounts_eth_mint_slot_idx;
      ```
- [ ] Roll the new image; migration Job's `bridge migrate` should
complete in well under a minute.
- [ ] Verify both indexes exist as `indisvalid = true`:
      ```sql
      SELECT indexrelid::regclass, indisvalid FROM pg_index
       WHERE indexrelid::regclass::text IN (
         'sol_reward_disbursements_challenge_specifier_idx',
         'sol_claimable_accounts_eth_mint_slot_idx'
       );
      ```
- [ ] Verify missing-row count drops as expected (per #829's test plan).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Author: rickyrombo

ddl/migrations/0201_backfill_missing_reward_disbursements.sql

@@ -15,24 +15,33 @@
 -- account. Rows whose user record no longer exists are intentionally skipped;
 -- they would need on-chain signature replay (via program.Indexer) to recover.
 
--- CREATE INDEX CONCURRENTLY cannot run inside an explicit transaction, so
--- these statements stay outside the BEGIN/COMMIT below. psql executes each in
--- its own implicit transaction. Both indexes pay off well beyond this
--- migration: the first lets the dedup LEFT JOIN on (challenge_id, specifier)
--- use an index instead of a sequential scan; the second lets the live
--- reward_manager indexer (and this migration's LATERAL lookup) resolve a
--- user's current claimable account in O(log n) rather than scanning the table.
+BEGIN;
+
+-- Build both indexes inside the migration transaction (non-CONCURRENTLY) so
+-- the writes are atomic with the backfill and not subject to virtualxid waits
+-- against concurrent transactions on this DB (notably the legacy Python
+-- index_rewards_manager Celery task on discovery-provider, which keeps long
+-- challenge_disbursements transactions open and can make CONCURRENTLY hang
+-- indefinitely). Regular CREATE INDEX takes a ShareLock on the target table:
+-- writes are blocked for the duration of the build, but both target tables
+-- have light write load (reward_manager EvaluateAttestations and claimable
+-- token creations are sparse on-chain) and the build itself completes in
+-- seconds at current row counts.
+--
+-- Both indexes pay off well beyond this migration: the first lets the dedup
+-- LEFT JOIN on (challenge_id, specifier) use an index instead of a sequential
+-- scan; the second lets the live reward_manager indexer (and the CTE below)
+-- resolve a user's current claimable account in O(log n) rather than scanning
+-- the table.
 
-CREATE INDEX CONCURRENTLY IF NOT EXISTS
+CREATE INDEX IF NOT EXISTS
     sol_reward_disbursements_challenge_specifier_idx
     ON sol_reward_disbursements (challenge_id, specifier);
 
-CREATE INDEX CONCURRENTLY IF NOT EXISTS
+CREATE INDEX IF NOT EXISTS
     sol_claimable_accounts_eth_mint_slot_idx
     ON sol_claimable_accounts (ethereum_address, mint, slot DESC);
 
-BEGIN;
-
 -- Skip the on_sol_reward_disbursement trigger for this transaction. The
 -- trigger fires per-row to create challenge_reward notifications and a
 -- pg_notify announcement for the Python ChallengeEventBus. For a one-shot