fix(db2): five bugs found by running the generator against real engines

[huyplb]

Follow-on to #263, which merged while this work was still going. Same branch of
effort, new base: everything here was written after that merge and none of it
is in main.

The theme: the generator had only ever been checked against strings and SQLite.
Pointing it at the real servers — six of which were already running in
docker compose, plus DB2 pulled for this — found five bugs in a day.

Bugs

DB2 left tables unwritable after a column drop. DB2 puts a table into
reorg-pending after DROP COLUMN: SELECT still works, every INSERT/UPDATE/
DELETE fails with SQL0668N reason 7, and so does rebuilding the table's indexes.
The migration reported success and handed back a table nobody could write to —
and because reads kept working, it could be a long time before anyone connected
the two. New postColumnChangeStatements hook emits
CALL SYSPROC.ADMIN_CMD('REORG TABLE …') before the keys and indexes are rebuilt.

Every DB2 comparison carried six phantom objects. SYSCAT.ROLES was read
unfiltered, so DB2's own built-in roles (SYSDEBUG, SYSGEOADM, SYSTS_*) appeared
as user objects in every schema. They cannot be recreated — DB2 reserves the SYS
prefix and answers CREATE ROLE SYSDEBUG with SQL0707N — so the migration also
carried eleven statements that can never succeed.

Sessions never worked on DB2 at all. The utility selected
SESSION_DB_PARTITION_NUM, which MON_GET_CONNECTION does not expose: SQL0206N,
dead on arrival. It is CURRENT SERVER now, which is what the database_name
column claims to be.

Migrations to DB2 never converged. DB2 rejects adding a NOT NULL column to a
populated table without a default (SQL0193N), so the dialect appends WITH DEFAULT — correct, and documented. But that leaves a default the source never
declared, so re-comparing straight after a successful migration reported the
same change again, for ever. New afterAddColumnStatements hook drops the
implicit default once the rows are backfilled.

A revert could roll itself back and report success. Table drops are ordered
before the ALTERs, and dropping a parent table takes its inbound foreign keys
with it — so ALTER TABLE … DROP FOREIGN KEY hit a constraint DB2 had already
removed (SQL0204N). DB2 has transactional DDL, so that one statement rolled the
entire revert back. The dialect already wraps its DROP TABLE/VIEW in a
CONTINUE HANDLER FOR SQLSTATE '42704' because DB2 has no DROP IF EXISTS; the FK
drop simply never got the same treatment, though the generic fallback it
overrides says DROP CONSTRAINT IF EXISTS for exactly this reason.

Coverage added

generated-ddl-live.test.ts, gated behind FOX_IT_DB=1 so CI stays DB-free:

docker compose up -d
FOX_IT_DB=1 npx vitest run apps/web/src/backend/modules/generated-ddl-live.test.ts

• CREATE and ALTER of hostile schemas (spaces, reserved words, punctuation,
  non-ASCII, index + FK) on Postgres, MySQL, MariaDB, SQL Server, CockroachDB,
  YugabyteDB and DB2.
• Procedures and functions, round-tripped: create natively, introspect,
  regenerate into a second schema, execute. Asserting "the object exists" would
  pass on a body that is empty, missing its terminator, or has the source schema
  baked in. All four engines with a routine spec pass.
• A write-back probe after each ALTER, because "the statements ran" and "the
  table still works" are different claims.

Notes for review

Three harness faults produced confident greens before any of the above was
visible, and each is now guarded — worth knowing if you extend this file:

• The liveness probe was SELECT 1, which DB2 rejects (SQL0104N). DB2 was
  marked unreachable and every DB2 case passed in 0ms while touching nothing.
  Targets carry their own probe now, and unreachable engines call ctx.skip()
  so a skip can never again read as a pass.
• The post-migration check was a SELECT — exactly what reorg-pending still
  allows — so it went green against a table the user could not write to.
• MigrationModule.execute reports failure through its event stream
  ({type:'done', success:false, rolledBack:true}), not by throwing. A
  try/catch around it reported a rolled-back revert as applied.

Not every red was the product's: I ignored the bind params the utility builder
returns, omitted a required table argument, seeded a scratch schema from the
wrong side, and pointed a round trip's source and target at the same schema.
Those were fixed in the harness before any bug above was reported.

Verification

• npx vitest run — 1798 passed, 87 skipped
• FOX_IT_DB=1 live suite — 53 passed, 3 visibly skipped (engines with no routine spec)
• cd apps/web && npx tsc --noEmit — clean; eslint — 0 errors
• End to end on the shipped DB2 samples: 30/30 statements execute, re-comparing
  after the migration reports no differences, and after a Lokee revert the
  new version's root hash equals v1's — content-addressed proof the schema
  came back identical. DEMO_A is untouched by the run.

🤖 Generated with Claude Code

---

Note

High Risk
Changes DB2 migration DDL, transactional revert behavior, and schema comparison output—areas that directly affect customer database writes and migration success reporting.

Overview
Fixes five DB2 issues uncovered by executing generated DDL on real servers (not just SQLite parsing), and adds an optional live test harness (FOX_IT_DB=1) for CREATE/ALTER, routine round-trips, and post-migration write probes.

DB2 migration generator gains dialect hooks afterAddColumnStatements and postColumnChangeStatements, wired in SqlGeneratorModule before index/key rebuilds. DB2 now drops the implicit default after ADD … WITH DEFAULT (so re-compare converges), runs REORG TABLE via SYSPROC.ADMIN_CMD after column drops/type changes (avoids reorg-pending tables that still SELECT but reject writes), and wraps FK drops in the same SQLSTATE 42704 handler as other drops so transactional DDL does not roll back the whole plan when the constraint is already gone.

DB2 introspection filters built-in SYS% roles from SYSCAT.ROLES / ROLEAUTH so comparisons no longer include phantom roles and impossible CREATE ROLE statements.

DBA Sessions utility for DB2 uses CURRENT SERVER AS database_name instead of the invalid SESSION_DB_PARTITION_NUM column (SQL0206N).

UI: TopToolbar drops unused PROVIDER_SETTINGS / browse-related store fields (no functional toolbar change in the diff).

Unit tests cover DB2 REORG ordering, DROP DEFAULT convergence, and FK drop tolerance; live tests skip unreachable engines per-dialect probe (e.g. DB2 FROM SYSIBM.SYSDUMMY1).

^{Reviewed by Cursor Bugbot for commit 45b2016. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_6b1037bb-b449-4f64-8669-1ac9a7697026)