fix(hasura): make 1741520400001 teams_name_unique migration idempotent

[acmeguy]

Summary

Unblocks the ArgoCD hasura-migrations-job PostSync hook, which has been failing on every sync and blocks all future Synmetrix deploys — including the recently merged Model Management API (#45).

The migration was previously:

DROP INDEX IF EXISTS public.teams_name_unique;
ALTER TABLE public.teams ADD CONSTRAINT teams_name_unique UNIQUE (name);

This crashes on any environment where the constraint was already created (locally on retry, or in the intermediate state after a partial apply):

cannot drop index teams_name_unique because constraint
teams_name_unique on table teams requires it

DROP INDEX refuses to drop an index that backs a UNIQUE constraint — the constraint owns the index.

Fix

Replace the two blind statements with a DO block that branches on the current DB state and short-circuits when the desired end state already holds:

Starting state	Action
(a) expression index teams_name_unique exists without a constraint	DROP INDEX then ADD CONSTRAINT
(b) plain UNIQUE constraint teams_name_unique already present	no-op, return
(c) neither exists	ADD CONSTRAINT

Detected via pg_constraint + pg_indexes lookups rather than bare SQL statements.

Also guarded

The pre-existing UPDATE public.teams SET name = lower(trim(name)) … was itself failing with a duplicate-key violation on environments where two rows normalize to the same value ("Default team" + "default team" is a real case observed on the dev cluster and locally). The UPDATE now skips rows whose normalized form already exists in another row. The constraint is case-sensitive on the exact stored string, so the two rows coexist under the new constraint and the application (which always writes lower(trim(…))) only ever writes the normalized form going forward.

Test plan

• Applied forward against local dev DB in state (b): success in <1 s, migrate status shows every migration Present/Present.
• node --test on services/cubejs + services/actions: 475 / 479 pass (the 4 pre-existing unrelated failures unchanged).
• scripts/lint-error-codes.mjs: green.

State (c) follows the direct ADD CONSTRAINT path — trivially correct.
State (a) reproduces the original forward intent — DROP INDEX + ADD CONSTRAINT — and was the path the old migration was already trying to run; it just needed to be gated so it doesn't run in state (b).

Not in scope: fixing the symmetric bug in down.sql (cannot recreate the expression index while duplicate normalized values exist). That path is only hit during intentional rollbacks and is not on the deploy critical path.

🤖 Generated with Claude Code