Migration sentry

[vijayfractl]

This PR adds migration validation and simulation to prevent unsafe or broken migrations from being applied.

src/runtime/resolvers/sqldb/database.ts:

• getSchemaDiff() — Compares the in-memory model against the actual database schema and returns pending SQL queries.
• simulateMigration() — Runs a pre-flight check before any migration is applied:
  • Postgres: Executes all migration queries inside a transaction, verifies schema convergence, then always rolls back. Catches SQL errors before they hit your real schema.
  • SQLite/SQLjs: Dry-run that flags destructive DDL (DROP TABLE, DROP COLUMN) via regex.
• validateSchemaInProd() — Called at startup when NODE_ENV=production. If the database schema doesn't match the app model, it throws and prevents the app from starting.
• maybeHandleMigrations() — Now runs simulation before applying any forward migration. If simulation fails, the migration is aborted with detailed error output.

test/runtime/migration-validation.test.ts (new):

• Tests that getSchemaDiff() returns no diff after sync, and detects missing columns.
• Tests that simulateMigration() succeeds when schema is in sync.
• Tests that the dry-run validator flags destructive DROP TABLE operations.

---

Migration System in Agentlang

How NODE_ENV Affects Behavior

• unset / development (DEV mode): Schema auto-sync is on. TypeORM silently adjusts tables to match model. No explicit migration needed.
• test (TEST mode): Same as dev — auto-sync enabled for test fixtures.
• production (PROD mode): Schema auto-sync is off. App refuses to start if schema doesn't match model. Must run migrations explicitly.

Migration Flow

1. generateMigration — Diffs in-memory model vs database schema, produces up/down SQL queries, saves them as a agentlang/Migration entity without executing.
2. runMigrations — Generates the diff, then:
   - Simulates first: On Postgres, runs all queries in a transaction then rolls back. On SQLite, does a dry-run with regex checks for destructive DDL (DROP TABLE, DROP COLUMN).
   - Validates convergence (Postgres only): After simulation, re-diffs to confirm schema fully converged.
   - If simulation passes, executes all queries in a single transaction and saves the migration record.
3. undoLastMigration — Loads the stored downQueries and executes them.
4. initSchema — Initializes schema from scratch (uses auto-sync).

Production Startup Validation

validateSchemaInProd() runs at startup when NODE_ENV=production. If there's any schema diff, it throws an error and prevents the app from starting, forcing migrations to be run before
deployment.

What App Maintainers Should Know

• Always run migrations before deploying to production. The app will refuse to start if the schema is out of sync. Use generateMigration to preview, then runMigrations to apply.
• Simulation is stronger on Postgres than SQLite. Postgres simulation is transactional and verifies convergence. SQLite only does pattern-matching for DROP TABLE/DROP COLUMN — other issues
  may slip through.
• Destructive operations are flagged during simulation, but review generated queries before running in production regardless.
• Migrations are transactional — all queries run in a single transaction. If any query fails, the whole migration rolls back (on databases that support DDL transactions).
• Dev auto-sync can mask migration problems. Your dev environment silently adjusts the schema, so migration issues won't surface until deployment. Periodically test your migration path
  against a production-like database.
• Keep down-queries valid. The undo mechanism relies on stored downQueries. Manual database alterations outside of migrations will break undos.