migration-reviewlisted

This is a gate: read the migration diff, run all five checks below against it, and emit a PASS/FAIL verdict per check with a cited line for every violation. A check with no matching pattern in the diff is PASS by default — say so, don't skip it silently. ## The five checks ### 1. Destructive ops carry a two-phase plan A `DROP COLUMN`, `DROP TABLE`, or `RENAME COLUMN`/`RENAME TABLE` is only safe once nothing still reads or writes the old name. FAIL any destructive statement unless the PR shows the deprecation already happened: a prior migration that stopped writes to the column/table, application code in the same PR that no longer references it, or a linked ticket confirming a phase-one migration already shipped. A destructive statement with no such evidence is a FAIL regardless of how trivial the column looks. ### 2. New columns on hot tables get a non-locking default `ADD COLUMN ... DEFAULT <constant literal>` is metadata-only on Postgres 11+ and safe. Anything else — `now()`, `gen_random_uuid()`, a subquery, any volatile or STABLE function — forces a full-table rewrite under `ACCESS EXCLUSIVE` on every Postgres version, hot table or not. FAIL any `ADD COLUMN` on a hot table whose default isn't a constant literal. Treat a table as hot unless the PR or schema comments state it's low-traffic; when unsure, treat it as hot. ### 3. Every index on a big table is CONCURRENTLY FAIL any `CREATE INDEX` or `CREATE UNIQUE INDEX` on a big table that omits `CONCURRENTLY`. Also FAIL a