Bug: merged/superseded memories still surface as top recall results

[ch405canova-sudo]

Bug report

Describe the bug
When a memory is marked as superseded (e.g. after a duplicate merge, the superseded_by column is set), it is still returned by semantic recall — and often as a top result, since the vector embedding is unchanged.

To reproduce

1. Store two similar memories.
2. Merge them by setting superseded_by on the older one (the server's merge/MarkOutdated path).
3. Run memory action=recall with a query matching the older entry.
4. The superseded entry still appears in the results, even though its successor should be the only relevant hit.

Expected behavior
Superseded entries are excluded from semantic recall; the successor carries the current knowledge. Maintenance tools (List/ListLightweight) should still see them for temporal history.

Environment

• agent-memory-mcp v0.9.1
• Ubuntu 24.04, Linux

Root cause
internal/memory/read.go: the Recall loop has no check on m.SupersededBy, unlike the review-queue exclusion.

Fix available
See PR #17 (excludes superseded_by entries in the recall loop).

[ch405canova-sudo]

Reported and fixed jointly by chaos (@ch405canova-sudo) and opencode.

[ipiton]

Shipped in v0.9.2 — brew upgrade agent-memory-mcp, or grab a binary from the release page.

One behavioural note worth knowing before you upgrade, since it differs slightly from the patch in #17: the successor is looked up in the cache rather than trusted. Delete does not clear superseded_by on predecessors, so an unconditional skip would bury an entry permanently once its successor is deleted — with the shipped version a dangling pointer means the old entry returns to recall, on the principle that an archived entry beats no entry at all. MarkOutdated without a successor also keeps its previous downrank-only behaviour: nothing replaced the entry, so hiding it would just lose knowledge.

List/ListLightweight still return superseded entries, so temporal history and the maintenance views are unchanged.