feat(memory): core Episode projection schema migration (plan-20260926 DM-01)

[genedna]

Intent

Implements task card DM-01 of docs/development/plan/plan-20260926.md (MEM-01/02 deterministic projection). This is migration A: the 2026092901_memory_core forward-only schema that backs the upcoming libra memory determinism surface (supersedes plan-20260819 R30's M2-* scope; DM-00 already registered the R30 retirement).

Changes

• Add sql/migrations/2026092901_memory_core{,_down}.sql creating three zero-authority, rebuildable projection tables per the frozen Schema 规范: memory_episode, memory_episode_evidence, memory_projection_state (forward-only, ADR-DM-13).
• Register the migration in src/internal/db/migration.rs (registered count 66→67, max_registered_version 2026092701→2026092901) and sql/migrations/README.md.
• Add db_migration_test coverage: three-table creation, frozen column/CHECK/UNIQUE/PK/FK vocabulary, idempotent second run, FK-reverse down drops, Repository-role-only (config ledgers untouched).
• Update branch-convergence registries for the new tip; add the #[serial(env)] SERIAL_REGISTRY row; sync tests/INDEX.md.
• Bump release surface to 0.30.31 (REL-DM-01 independent release point) + CHANGELOG [0.30.31] section.
• Update plan status: DM-01 locally-accepted; REL-DM-01 release + ER-05 review pending.

Tests run

• cargo test --test db_migration_test — 101/101 passed (incl. memory_core_*).
• cargo test --lib internal::db::migration::tests::builtin_runner_registers_current_builtin_migrations — passed.
• cargo test --test compat_serial_registry — 25/25 passed.
• cargo test --test compat_version_surface_sync — 2/2 passed.
• cargo +nightly fmt --all --check — clean.
• cargo clippy --all-targets --all-features -- -D warnings — clean.

No public CLI behavior changes (internal schema only); full T-1 nextest suite running in parallel.

[fleeto]

via Codex

Reviewed head 275733eda3c2d4c4a3dec266c412bbd0c62d128f. Two P1 findings are attached inline: incompatible pre-existing Memory tables can be silently certified by the new migration, and the release notes omit the old-binary compatibility boundary. Recommend addressing both before merging.

Validation: static review of the PR diff and migration/open paths, plus isolated SQLite probes using the actual SQL from this PR and PR #579. Fresh-schema probes passed for repeated up preserving rows, CHECK/UNIQUE enforcement, evidence defaults, FK cascade, and down cleanup. The old-schema probe reproduced a successful upgrade receipt with missing required columns. I did not run the Rust test suite.

[fleeto]

via Codex

[P1] Validate pre-existing Memory table shapes before accepting this migration

CREATE TABLE IF NOT EXISTS silently keeps an existing table even when it does not have the frozen DM-01 shape, and the migration runner then commits the new schema receipt. This has a concrete branch-upgrade reproducer: create the Memory tables using PR #579's 2026092601_memory_core.sql at c4d5f749ac7b9dfc7b07b27a59885f761f1c99df, then apply this SQL. It succeeds, but memory_projection_state still has fts_synced_fingerprint and lacks revoked_count and aged_out_count; SELECT revoked_count, aged_out_count FROM memory_projection_state fails with no such column: revoked_count. The old evidence table also lacks this migration's resolution_status default.

Repositories that tried the earlier Memory branch are therefore certified as upgraded without the schema expected by subsequent Memory cards. Please inspect all three existing tables inside the migration transaction and either reject incompatible shapes with an actionable error or explicitly convert them. Add a regression fixture proving that a mismatched shape cannot commit the 2026092901 receipt; silently dropping existing tables is not a safe substitute.

[fleeto]

via Codex

[P1] Document the old-binary compatibility boundary in the release notes

Although this adds no new CLI command, applying 2026092901 changes the repository-open contract: binaries whose registry ends at 2026092701 (including the preceding release) reject the repository as a future schema. Reinstalling the old binary does not undo the receipt. This consequence is acknowledged in ADR-DM-13 and the internal SQL comments, but this release entry says No public CLI behavior changes and gives users no downgrade/recovery guidance.

Please explicitly state the minimum compatible version after migration, that recovery uses a compatible newer binary/forward fix rather than binary downgrade alone, and that users needing a return to the old version must retain a consistent pre-upgrade backup. Reflect the boundary in the user-facing compatibility documentation as well.