[tgarciai]

Part of #909.

Summary

The reported loss does not reproduce on 5da095ee (v0.25.0), and it does not reproduce with the released 0.24.0 binary either. Replay builds the same contains_entry edges as the live write path, so VisualLabel::catalogue returns the same catalogue. This PR adds no product change. It adds the regression test the issue asks for, so the "Expected" clause is now pinned.

Evidence (scratch copy of the real user store, 474 events, 20 abouts)

cp -a ~/.local/share/kmp/default $SCR/src-store, then export to full.jsonl and import into a fresh dir ({"events_imported":474,"mutations_applied":16085}). HOME and XDG pointed at scratch dirs the whole time.

• contains_entry edges (relations_by_source, k3='contains_entry', value JSON with dimension/scope_id): source 2473, replay 2477. The diff shows exactly 4 extra lines, all for fixture:storea / fixture:storeb. Every other edge is byte-identical, project:made included.
• Full wake catalogue of project:made, read page by page through projection.next_action (51 pages on the source, 116 on the replay): 108 labels in each. The sorted diff is empty.
• First page: 6 labels in both stores, with sections.labels = {remaining: 102, returned_on_page: 6}.
• Other import paths: import --from <store> --about project:made and import --from <bundle> --about project:made, both read in full, give the same 108 labels with an empty diff.
• 0.24.0 binary (~/.claude/plugins/cache/underpass/kmp/0.24.0/bin/kmp-mcp), same procedure: source and replay both return 108 labels, and both match the 0.25.0 catalogue with an empty diff.

The labels are a paged expansion that fills the byte budget after the core (see kmp_wake's labels description). So a page can show labels: [] while projection.sections.labels.remaining > 0. That is my best explanation for the original 3 → [] reading, but I could not reproduce it with the default budget, nor with an intent.

What the table-count deltas in the issue actually are

• aggregates 18→20, memory_anchors 18→20, nodes +6, relations_by_* +14: all of it is fixture:storea / fixture:storeb. Events 405/406 of the source log, with idempotency keys canary-storeA-v1 / canary-storeB-v1, are in event_log and idempotency but have no aggregate head, anchor, nodes or edges. append_in_transaction (crates/kmp-adapter-embedded/src/adapter/context_events.rs) writes the aggregate head, the log row and the idempotency row in one transaction, and no product path removes aggregates rows. rebuild_projections (replay.rs) leaves aggregates alone and projects every log event again. Projections deleted after the commit are the most likely cause, for example a manual canary cleanup like the one that left default-backups/kernel.sqlite3.pre-canary-cleanup.bak on 23 Sept; that is not proven. The events were already in the log by the 26 Sept bench export. Replay simply projects them again. This partial "source lags its log" state is limited to those two fixture abouts and does not touch project:made.
• detail_headers 1953→2331: every extra key is project:kmp. Headers came after many of those details had been written (detail_header.rs: "a detail whose header is absent is a projection that predates this record"). Replay writes a header for each detail, so this gap is expected and harmless.

Test

crates/kmp-mcp/tests/label_catalogue_round_trip.rs:

• writes labelled memories in two abouts, with several keys and values;
• uses kmp_relabel to move one entry from task=corte-3 to task=corte-5;
• runs kmp-mcp export and then kmp-mcp import through the real binary into a fresh store, with temporary HOME and XDG;
• reads every page of the wake catalogue from both stores, requires them to be equal, and pins the exact source catalogue.

Checks run locally

All of these ran with HOME and XDG set to scratch dirs:

• cargo fmt --all -- --check
• cargo clippy -p kmp-mcp --all-targets --locked -- -D warnings
• cargo test -p kmp-mcp --locked: 1256 passed, 0 failed
• scripts/ci/kmp-mcp-architecture-gate.sh

Only kmp-mcp was touched (a test file), which is inside DEV_PACKAGES.