new-migration

# Adding a schema migration Read `src/db.ts` around the newest migration before writing anything. The archive baseline is v21 and the current value lives at `src/db.ts:24`. ## The rule that matters most **A migration is frozen the moment it is committed to a branch.** A dogfooding archive may already have run it, and re-running an edited version is not possible. If review asks for a change to a migration that is already committed, add a new version rather than editing the old one. Never edit a committed migration, even on an unmerged branch. This is not theoretical. Migration 11 was once run in an uncommitted form against the live archive, which left a stray `session.context_compaction_count` column that the fingerprint gate then rejected on open. Repairing it took a guarded migration of its own rather than a rebuild. ## Steps 1. **Write the migration guarded.** Follow the existing style in `src/db.ts`. Use the `hasTable` and `hasColumn` helpers so a partially migrated archive converges instead of throwing, then stamp it. ```ts if (version < 22) { if (hasTable(db, "session") && !hasColumn(db, "session", "my_column")) { db.exec("ALTER TABLE session ADD COLUMN my_column INTEGER"); } db.query( "INSERT INTO schema_migrations (version, applied_at) VALUES (22, datetime('now'))", ).run(); } ``` `assertSchemaMatchesBaseline` runs after the migration chain, so a migration that leaves the database disagreeing with `src/s...