Diff renders a serial column's nextval default without its sequence, so the generated DDL fails to apply and takes the table's indexes down with it

[jryannel]

Found by sqlb-survey on a second corpus (mind-vm/studio-apps, 10 app schemas, 233 tables). This is the only defect in either survey that produces DDL which does not run — every other gap so far degrades to a skip note.

What happens

process-mining has:

CREATE TABLE coprocess_steps (
    seq BIGSERIAL NOT NULL,
    ...
);
CREATE INDEX coprocess_steps_session_idx ON coprocess_steps (session_id);

Introspect models the column fine — it reads as bigint with default nextval('coprocess_steps_seq_seq'::regclass). Diff then renders the column with that default but never emits the CREATE SEQUENCE, so applying the DDL gives:

FAIL create table coprocess_steps — ERROR: relation "coprocess_steps_seq_seq" does not exist (SQLSTATE 42P01)
FAIL index coprocess_steps_session_idx — ERROR: relation "coprocess_steps" does not exist (SQLSTATE 42P01)

Two failures from one cause: the index fails behind the table that never got created.

Why it matters more than a skip

The table is reported clean in Phase B — nothing is dropped, nothing is noted. The schema looks importable and the failure only appears when the DDL is applied. A skip note tells an adopter what they lose up front; this tells them nothing until the bootstrap breaks.

Shape

Same family as #115: Diff emits DDL referencing a dependency object it never creates. #115 is the extension, this is the sequence. Whatever ordering pass fixes one probably wants to know about the other.

Where it did not show

valiro has no serial columns anywhere — 68 tables, 0 apply failures. It took a corpus with one BIGSERIAL to surface, which is the argument for surveying more than one schema.