Compliance erasure: pond erase as the single sanctioned deletion

[tenequm]

Context

From the 2026-06-05 SessionStore assessment: pond needs exactly one sanctioned deletion path, specified tightly enough to be compliance-ready (right-to-erasure), while everything else stays append-only (session-durable-copy 5.4, additive-sync 6.6.d).

Append-only and erasure do not conflict: append-only constrains events within a session (never mutate/reorder); erasure retires a whole session object. Cascade to child sessions is the deletion-side mirror of adapter-lineage-complete-restore (6.2): restore restores children, erase erases children.

Requirements

• New spec rule (working name: session-compliance-erasure): the ONLY deletion pond performs; everything else remains append-only.
• Operator-only op: pond erase <session-id> (CLI/HTTP). Never exposed on the MCP read surface.
• Cascades to child (subagent) sessions.
• Resurrection-proof: an erased-key denylist consulted by the ingest path, otherwise pond sync from a still-present source rebuilds what was just erased. This is the one genuinely hard sub-point.
• True byte purge, not tombstones: Lance delete predicate -> compaction -> version-history cleanup -> blob purge. Time-travel otherwise retains the bytes; compliance delete must reclaim them.
• Output names what was erased and what the denylist now blocks.