fix(db): duplicate migration version 000057 on base (cleanup_universal_plans vs drop_user_role_to_groups) #970

Confirmed: duplicate migration version 000057 on base

origin/feat/multicloud-web-frontend carries TWO distinct migrations at version 000057:

• 000057_cleanup_universal_plans.{up,down}.sql (+ _test.go) - from ops(plans): clean up existing universal plans (DB rows with no plan_accounts entry) #742 / PR ops(plans): migration to clean up universal plans (closes #742) #802
• 000057_drop_user_role_to_groups.{up,down}.sql (+ _test.go) - from Revamp authorization: group-membership-only (remove roles), require >=1 group per user #907 (group-only authz)

golang-migrate requires unique, monotonic versions. Impact:

• migrate up on a fresh DB fails (duplicate version).
• check-migration-conflicts fails on the merge ref for EVERY open PR (observed during work on sec(api/plans): stop leaking raw account UUID + DB error in plan-account validation log #969).
• Same defect class as the earlier 000058 collision (Purchaser group), which was repaired via the relocate-style migration 000064 (bug(auth/seed): Purchaser group never seeded -- UUID collision with Standard Users (migrations 000057 vs 000059) #942).

Decision needed (deployed-DB state)

Unlike the earlier collisions (which surfaced while deploys were already failing), deploys have been SUCCEEDING here (/version live at git_sha 83d5dc8), so one of these 000057 migrations may already be applied to the QA (and/or prod) database. That makes a naive git mv renumber risky: the DB's schema_migrations would still record 000057 as applied, and renaming the file to a higher number makes migrate see a "missing" 000057 plus a "new" higher version.

Options:

1. If neither 000057 is applied yet on any live DB: git mv the later / less-foundational one (cleanup_universal_plans) to the next free slot (000060; base jumps 000059 -> 000063, so 000060/61/62 are free), update its _test.go, done.
2. If one IS applied: reconcile schema_migrations on the live DB(s) and use a relocate-style approach (mirror what 000064/bug(auth/seed): Purchaser group never seeded -- UUID collision with Standard Users (migrations 000057 vs 000059) #942 did for the Purchaser group) so the renumber is idempotent and doesn't re-run or strand state.

Ask

Which 000057 (if either) has been applied to the QA/prod DB? With that, I can land the correct fix (renumber vs reconcile-and-relocate). Do NOT renumber blindly until this is known.