refactor(db): replace the kysely Migrator with Flyway

[nourshoreibah]

Stacked on #400. PR 2 of the Aurora DSQL migration — the migrator swap, still entirely on RDS, so a failure here is unambiguous.

Why

Aurora DSQL has no advisory locks and allows one DDL statement per transaction. Kysely's PostgresAdapter takes a pg_advisory_xact_lock on every run and declares supportsTransactionalDdl = true, so Migrator wraps the whole run in one transaction. Neither is configurable through Migrator options, so the migrator has to go before the engine can.

Flyway also covers both engines from one migration corpus, and it deletes machinery we were maintaining by hand.

What changed

• Migrations renamed to Flyway's V<version>__<description> form. Pure renames — the diffstat shows 0 changed lines for all 8.
• db/flyway.sh is the single place Flyway is configured. It resolves the connection exactly as src/config.ts does (including the RDS CA bundle) and runs the pinned image when no flyway is on PATH, so docker stays the only prerequisite. Credentials go through the environment, never argv.
• Production is adopted, not replayed: baselineOnMigrate with baselineVersion pinned at the last kysely-era migration.
• testkit stamps flyway_schema_history instead of kysely_migration. Checksums are left NULL, which Flyway treats as "not mine to validate" — reimplementing its CRC32 would be a second thing to keep in step for no benefit.
• The schema-comment fingerprint stays but Flyway does not write it, so npm run fingerprint does, and the Makefile and CI call it before generating types.
• The immutability guard is keyed by version rather than by path, which is what production's schema history actually pins. It now catches content edits, renames and deletions separately.
• dsql-lint runs advisory-only on newly added migrations, with ${async} substituted first (it parses SQL, and ${async} is not SQL).

Verified against PostgreSQL 16

• from-scratch flyway migrate produces a schema byte-identical to applying the same files directly — the pg_dump --schema-only diff is empty
• re-running is a no-op; flyway validate passes; flyway info shows nothing pending
• a pre-Flyway schema (tables, no history table) is adopted by baselining and re-runs nothing
• an empty target is refused by the deploy preflight; a tracked-but-drifted one is too
• testkit round-trips: rebuild leaves 8 history rows, the fingerprint verifies, resetData does not truncate the history table, rollups stay consistent
• generated types are unchanged, with flyway_schema_history excluded from codegen
• the new immutability guard passes this PR and rejects an edit, a rename and a deletion

Deviations from the plan, and why

1. org.flywaydb:flyway-database-dsql does not exist as an installable artifact. It is not on Maven Central and not bundled in the Flyway CLI 13.5.0. It lives only as source in flyway/flyway-community-db-support (added 2026-08-05, parent pinned to Flyway 10.26.0 while the CLI is 13.x). AWS's software.amazon.dsql:aurora-dsql-flyway-support 2.0.0 is published, but its README declares itself deprecated in favour of the module you cannot install. This is a PR 3 decision, not a PR 2 blocker — nothing here needs it — so the DSQL jars are not added to the image yet.
2. The DSQL module does not auto-split DDL and DML into separate transactions. The plan recorded that it does. Its README says the opposite: Flyway commits a whole file as one transaction, so each migration file needs exactly one DDL statement, or an executeInTransaction=false sidecar. Our baseline creates 7 tables plus indexes in one file, and the corpus still contains the plpgsql that V20260906215733 drops — so PR 3 needs a squashed DSQL baseline, not a replay of history.
3. The SERIAL → CREATE SEQUENCE + INT DEFAULT nextval rewrite moved to PR 3. In PR 2 it would break this PR's own acceptance criterion (schema identical to the kysely-built one) and silently break TRUNCATE ... RESTART IDENTITY in testkit, whose compensating fix the plan puts in PR 3.
4. flyway validate cannot replace the git immutability guard. CI migrates a fresh database, so there are no prior checksums to violate; the only PR-time protection is the git one. Kept and improved rather than deleted.
5. kysely could not be removed entirely — it is a required peer dependency of kysely-codegen. Moved to devDependencies.
6. dsql-lint gating is advisory. Linting the whole corpus can only ever fail, because history contains statements a later migration already dropped.

Two plan verification items are now settled empirically: INT ... DEFAULT nextval(seq) with CREATE SEQUENCE ... CACHE 1 passes dsql-lint clean, and ${async} placeholders break its parser.

Note

The checks and migrate jobs now pull the Flyway image (~392 MB). Worth caching if it shows up in CI times.

🤖 Generated with Claude Code

[github-actions]

This PR contains a database migration

(no newly added migration files in this PR)

It will be applied to the production database automatically when this PR merges, before the new lambda code is deployed. Please confirm before requesting review:

• Applied and tested locally. cd apps/backend && make migrate, then run the affected lambda's tests (cd apps/backend/lambdas/<name> && npm test). make show-migrations shows what applied.
• Safe for the code that is live right now. During the deploy window -- and indefinitely if the deploy fails -- the currently deployed lambdas run against your new schema. Additive changes (CREATE TABLE, nullable ADD COLUMN, CREATE INDEX) are fine in one PR. DROP COLUMN, renames, ADD COLUMN NOT NULL with no default, and new UNIQUE/CHECK/FOREIGN KEY constraints need two merged PRs -- see the expand/contract rules in apps/backend/db/README.md.
• Kept separate from unrelated changes. A migration PR should ideally contain the migration, the code that needs it, and nothing else. It changes production state, it is the one thing here that redeploying cannot roll back, and a reviewer should be able to see the whole schema change without scrolling past unrelated work.
• No already-merged migration was edited. Fix an old migration by adding a new one; there is no down.

shared/types/db-types.d.ts is regenerated and pushed to this branch automatically -- don't hand-edit it. Expect one red migrations-fresh check before that commit lands.

[github-actions]

Database Types Check Complete

The database schema files were modified, but the regenerated TypeScript types are identical to the existing ones.

No changes were needed and the type definitions are already up to date.

[github-actions]

Database Types Check Complete

The database schema files were modified, but the regenerated TypeScript types are identical to the existing ones.

No changes were needed and the type definitions are already up to date.

[github-actions]

Database Types Check Complete

The database schema files were modified, but the regenerated TypeScript types are identical to the existing ones.

No changes were needed and the type definitions are already up to date.

[github-actions]

Database Types Check Complete

The database schema files were modified, but the regenerated TypeScript types are identical to the existing ones.

No changes were needed and the type definitions are already up to date.