ci(core): reject downgrade-incompatible database migrations #33898

Problem

Core database migrations can currently make the user database incompatible with older OpenCode binaries. This breaks downgrade/recovery workflows and version-skewed installs that share the same database.

A recent example is #33378, whose 20260622142730_simplify_session_context_epoch migration dropped:

• session_context_epoch.agent
• session_context_epoch.replacement_seq
• session_context_epoch.revision

After v1.17.10 applies that migration, downgrading to v1.17.9 can fail with SQLiteError: no such column: replacement_seq.

The existing bun packages/core/script/migration.ts --check verifies generated schema/registry consistency, but does not detect backward-incompatible schema changes. Related version-skew failures have also been reported in #31204.

Proposal

Add a migration compatibility check to CI, preferably as part of packages/core/script/migration.ts --check:

1. Inspect only migrations added by the PR (grandfather existing migration history).
2. Apply each new migration to the previous schema and compare sqlite_master, pragma_table_info, indexes, and foreign keys before/after.
3. Fail when an existing table or column is removed or renamed, or when a change makes old writers incompatible (for example, adding a required column without a compatible default).
4. Statically reject obvious destructive SQL such as DROP COLUMN, DROP TABLE, and table/column renames so failures have a clear message.
5. Provide an explicit, narrowly scoped compatibility escape hatch for intentionally destructive migrations, requiring review and rationale.

The default migration policy should be expand-contract: stop reading/writing obsolete fields first, but retain their physical columns and compatible defaults for the supported downgrade window.

Acceptance criteria

• A PR containing ALTER TABLE ... DROP COLUMN ... in a new Core migration fails CI by default.
• The failure explains that newer databases must remain usable by the supported previous OpenCode version(s).
• Existing historical migrations do not fail the new check.
• An explicit reviewed override exists for intentional compatibility breaks.
• Ideally, CI also includes a smoke test that upgrades a database with the candidate build and then runs the previous released binary against it.

cc @kitlangton