Migration safety: dry-run plan, lock-aware advisor, one-click rollback

[MUKE-coder]

Vision

Database migrations are the highest-blast-radius operation in any deploy. "Migration locked the table for 90 seconds during peak" is a story every senior engineer has lived. The framework's AutoMigrate is friendly for prototypes but dangerous at scale.

Proposal

A migration toolchain that grows up with the app:

• `grit migrate plan` — prints the SQL the migration will run, the estimated lock time per statement, and warnings for known-dangerous patterns:
  • `ALTER TABLE … ADD COLUMN NOT NULL` without a default → suggests two-step migration
  • `ALTER TABLE … ADD INDEX` → warns about lock duration on N-row tables
  • `DROP COLUMN` → blocks unless explicitly approved (data loss)
  • Destructive ops on tables > N rows → require an explicit `--i-understand` flag
• `grit migrate up` — runs the plan with progress reporting + automatic transaction wrap
• `grit migrate down` — auto-generated reverse migrations for every `up` (where reversible)
• Schema snapshots before/after every migration → `grit migrate restore ` rolls back to a snapshot
• Migration history in admin UI with diff view per migration

Why this is differentiating

Liquibase and Flyway exist; nothing comparable for Go + GORM + opinionated app frameworks. "Run a safe migration" is a recurring stress event for every engineering team.

Acceptance

• `grit migrate plan` catches an unsafe `NOT NULL` add before it locks production
• A migration that fails halfway can be rolled back to its pre-state in <30s
• Migration history is queryable + diff-able in the admin UI