fix(migrate-ts): stop meta migrate dropping a legacy Postgres serial PK's default

[dmealing]

Adopting metadata onto an existing Postgres table whose PK was created as legacy serial made meta migrate --from-db propose:

ALTER TABLE "work_item" ALTER COLUMN "id" DROP DEFAULT;

with no replacement generation mechanism. Applying it leaves id NOT NULL with nothing to populate it, so every insert that doesn't supply id starts failing — against a live table, on the first thing a new adopter does. serial PKs are what Drizzle, Prisma, Rails and SQLAlchemy all produce, so this is the most common pre-adoption shape.

It also violated the repo's own adoption doctrine — "adopting onto existing code? Metadata FOLLOWS the code" — by modernizing serial → IDENTITY as a side effect of adoption.

Root cause

Introspection is correct: it detects nextval(...) and sets identity = "increment", matching the expected side, so the identity dimension itself doesn't diff. The bug is the separate column-default comparison, guarded only against uuid on the strength of a comment claiming "an AUTOINCREMENT column has no DEFAULT" — true for SQLite and modern GENERATED ... AS IDENTITY, false for Postgres serial, which is sugar for integer + sequence + a real DEFAULT nextval(...).

The fix

An increment PK skips the default-diff only when the live default is that exact auto-sequence shape. A genuinely wrong, non-sequence default on an increment PK still reports as drift (two regression tests assert the change payload, not just a count). Detection lives in one shared isPgAutoSequenceDefault helper used by both introspection and the diff, so the rule can't drift into two spellings. The false comment is corrected.

No serial → IDENTITY modernization is introduced — if ever wanted it should be opt-in, never a side effect of adoption.

Verification

Ran against a real Postgres (ephemeral container), not a skipped integration test: live serial PK introspects with a genuine nextval(...) → diff emits no DROP DEFAULT → apply → re-introspect → re-diff empty → an insert omitting id succeeds and auto-populates. The last two assertions are what prove the bug fixed rather than silenced.

Unit suite 401/401 · package 688 pass / 19 skip / 0 fail · reviewed, one fix round, re-reviewed clean.

npm-only — schema is TypeScript-owned (ADR-0015).

Known residual (not addressed here)

The guard keys on the expected side, and identity is only set when @generation is explicit — so an adopter declaring identity.primary without @generation: increment still hits the destructive path. Widening to key on the actual side would swallow a deliberate @generation removal, so it needs a design ruling rather than a blind patch.