fix(migrations): unbreak main — 20260826180000 was claimed twice

[catomean]

main is red and nothing is deploying. Two migrations merged with the same version:

20260826180000_mention_queue_all_mentions.sql      (this session)
20260826180000_resolve_username_history_rpc.sql    (a parallel session)

Supabase keys schema_migrations on the version alone, so the second INSERT fails and every deploy aborts.

Why the symptom was confusing

cd.yml skips its deploy job unless the triggering CI run succeeded:

if: github.event_name == 'workflow_dispatch' ||
    github.event.workflow_run.conclusion == 'success'

So the visible signal was a CD run reporting skipped — main red, nothing shipped, and no red deploy to notice. Exactly the "CI is green, no check is red, and nothing deploys" shape this repo's CLAUDE.md warns about, arriving from the other direction.

Safe to rename

Neither migration had been applied to production — schema_migrations has no 2026082618% rows — so renaming loses nothing.

The lesson, since this is the second time today

The first collision was caught pre-merge by the Migration Replay gate and by the parallel session's own migrations-unique-version test. This one wasn't, because both PRs were green independently — the collision only exists in the merge, which neither branch tested.

Two green PRs can still make a red main. Picking a migration timestamp needs git ls-tree origin/main supabase/migrations/, not a glance at the local tree.

Verification

• migrations-unique-version passes
• production confirmed clean of both versions before renaming

🤖 Generated with Claude Code