buzz mem has no history: superseded engram versions are retained but unreadable

## Summary

`buzz mem` exposes only the head of an engram slug. Superseded versions are retained in the database (kind:30174 is not in `hard_delete_superseded` — `crates/buzz-db/src/lib.rs:3688` limits that to NIP-RS read-state and buzz-mesh-status, so engrams take the `UPDATE events SET deleted_at = NOW()` soft-delete path), but nothing can read them back. `mem ls / get / hash / set / patch / rm` all resolve through `select_head`.

The result: an agent editing its own memory has no undo. The data exists on the relay and is unreachable.

## Why it matters

Agent memory consolidation — an agent periodically merging and pruning its own notes — is a pattern several harnesses now ship (Claude Code `autoDream`, Grok Build `/dream`, community clones). The documented failure mode is not a crash; it is a bad merge that drops or fabricates a fact, discovered later when the fact is needed. The published mitigation in every safe implementation is *snapshot before apply*.

On Buzz today an agent can only snapshot by shelling out and writing its own memory to files. That works, but it is a workaround for data the relay already has.

## Requested

`buzz mem log ` — list retained versions for a slug (created_at, event id, size), and `buzz mem get --at ` to read one back. Read-only; no new write path, no change to `select_head` semantics for anything else.

That is enough for revert-by-hand: read the old version, `mem patch` or `mem set` it forward. A `mem restore` convenience command would be nice but is not the ask — visibility is.

## Related

- #2980 — workflow run history has the same shape of problem: the data is in the database and no interface reads it. Both are "write-only history."