[Bug]: Legacy snapshot restore and branch creation are unsafe after subject_id migration

[loveRhythm1990]

Is there an existing issue for the same bug?

• I have checked the existing issues.

Environment (optional)

Memoria v0.4.0 (27107f5) upgrading to v0.5.1/current main; deployment compatibility target: MatrixOne 3.0.11.

Actual behavior

Code inspection found two legacy-snapshot compatibility gaps after subject_id was added:

1. restore_table_from_snapshot deletes current rows before INSERT INTO target SELECT * FROM the historical snapshot. Historical and migrated tables have different column counts, so insertion can fail after deletion. These operations are non-atomic.
2. memory_branch with from_snapshot inherits the historical schema but does not reconcile new columns before registering the branch. Subsequent operations can reference missing subject_id.

This is a code-level finding, not a report of observed production data loss. Exact-version runtime reproduction is required.

Expected behavior

Restore legacy snapshots using explicit compatible column mapping and defaults for new fields, validating/materializing the source before touching current rows. A failed replacement must not leave current data deleted. Branches created from historical snapshots must satisfy the current schema before exposure.

Steps to reproduce

1. Create memories and a snapshot using the schema without subject_id.
2. Upgrade and run the subject_id migration.
3. Restore the historical snapshot; check data and failure safety.
4. Create a branch from that snapshot, then read/write it with current code.

Additional information

Affected: memoria-git/src/service.rs, memoria-mcp/src/git_tools.rs, and memoria-storage/src/store.rs.

Add regression coverage for populated/empty historical snapshots, repeated restores, failures before/after deletion, and legacy snapshot branches. Validate on MatrixOne 3.0.11 and the development version. This fix is independent of the Astra scoped-key PR.

[loveRhythm1990]

Confirmed the original failure on disposable official MatrixOne 3.0.11 (6a0394c) and 3.0.15 (43e871c) instances: after adding subject_id, the old DELETE followed by INSERT ... SELECT * fails on column count and leaves the test table empty. No production data was used.

A fix is prepared locally on fix/legacy-snapshot-schema-compat (209941e; not yet pushed/released):

• Materialize historical rows with explicit column mapping and current defaults before touching live rows.
• Replace live rows in one transaction, so an INSERT failure rolls back the DELETE.
• Reconcile historical branch subject_id/index before registration; clean up clones if migration fails.

Validation passed on both versions: 6 legacy-restore cases, 1 injected post-DELETE failure case, 46 MCP branch cases and 21 MCP snapshot cases. A Send-bound regression and Clippy checks also passed. CI explicitly invokes the DB-only transaction failure test.

Atomicity is per restored table; existing best-effort graph rollback semantics are unchanged. This is snapshot-fix validation, not approval of the full production upgrade.