feat(core): version the store schema with a migration runner

[RatulMaharaj]

What

The store applied its schema with CREATE TABLE IF NOT EXISTS on every open. That works until the first release that changes an existing table: databases already sitting on a volume keep the old shape and the agent starts failing at insert time. This PR gives the store a schema version and a migration runner.

How

• packages/core/store/migrations.ts holds an ordered, append-only list of migrations. The array position is the schema version, recorded in the database itself via PRAGMA user_version, so there is no extra journal table.
• On open, the Store applies each pending migration inside its own transaction and bumps the version in the same transaction. A failed migration rolls back completely and the next open retries from the same point.
• A database reporting a version newer than the build knows is refused with a clear error, so an older binary won't run against a schema it has never seen.
• Migration 001 is the baseline schema including the memories table from Persistent agent memory #37, kept idempotent (IF NOT EXISTS) on purpose: databases created before versioning report version 0 with some or all tables already present, and replay it harmlessly on first open.

No new dependencies; the runner is ~40 lines on node:sqlite.

Testing

• deno task ok passes (fmt, lint, check, 112 tests).
• New tests cover: fresh database reaches latest version, re-open is a no-op, pending migrations apply in order, pre-versioning databases upgrade with data intact, a failed migration rolls back and keeps the version, and a newer database is refused.
• Smoke-tested on disk: built a database file the way released v0.2.0 does, reopened it through the new Store, confirmed existing rows survive and the file gets stamped to version 1.

🤖 Generated with Claude Code