feat(gate): detect same-table/same-column collisions across differently-numbered migrations

[JSONbored]

Parent: #1936

Problem

scripts/check-migrations.mjs's collision logic only groups migration files BY FILENAME NUMBER — it never parses the SQL body to detect two DIFFERENT, individually-valid numbers adding the SAME column to the SAME table. repository_settings alone has taken 5+ independent ALTER TABLE ... ADD COLUMN migrations under unique filenames (0073, 0076, 0089 ×2, 0090, 0091 ×5), confirming this is the hottest actual collision surface in the schema.

Two concurrent PRs each independently picking the same column/table combination under different, individually-valid migration numbers would both pass CI, both show mergeable_state: clean (different files, no git conflict), and only fail at actual wrangler d1 migrations apply --remote deploy time — AFTER merge, with zero CI signal at all. This is strictly worse than the migration-numbering collision (issue: pre-merge content recheck for migration collisions), which at least fails loudly in CI/gate.

Requirements

• Extend scripts/check-migrations.mjs to parse the SQL body of every ALTER TABLE ... ADD COLUMN (and equivalent CREATE TABLE column lists) statement across ALL migration files, regardless of filename number.
• Group by (table, column) pair and fail the check if the same pair appears in more than one migration file.
• Must handle both SQLite/D1 and Postgres migration syntax if the self-host stack's dual-backend migrations differ in dialect.

Deliverables

• A new column-collision-detection pass added to scripts/check-migrations.mjs, run as part of the existing npm run db:migrations:check (already in the test:ci chain — no new CI wiring needed).
• A basic SQL statement parser/regex sufficient to extract (table, column) pairs from ADD COLUMN and CREATE TABLE statements without needing a full SQL parser dependency.
• Tests covering: a genuine collision (two files, same table+column) fails the check; two files touching the same table with DIFFERENT columns pass; a column rename/drop doesn't false-positive.

Acceptance criteria

• Running npm run db:migrations:check against a migrations directory containing two files that both add the same (table, column) fails with a clear, actionable error naming both files.
• No false positives against the current migrations/ directory (the check must pass cleanly on the existing, correct migration history).

Expected outcome

A same-column collision between two concurrently-merged, individually-valid migrations is caught in CI before merge, instead of surfacing as a silent wrangler d1 migrations apply failure at the next deploy with no prior signal.

[linear-code]

JSO-2492