Add replay-safe memory mutation and tombstone event semantics

[valiantone]

Context

HotMem can emit memory.created events with record state, but replay skips other event types because lifecycle and operational events do not provide a complete state-transition contract. Without replay-safe updates and removals, a later event range cannot reliably reconstruct the terminal state and deleted records may be resurrected.

What needs to be done

• Define versioned replayable create, replacement/update, and delete/tombstone events.
• Specify immutable envelope fields: record identity, namespace/scope, occurrence time, source/runtime identity, replay position, and payload schema version.
• Choose and document whether updates carry complete after-state, a versioned patch, or another deterministic representation.
• Define tombstone identity, retention, and compaction preconditions sufficient to prevent resurrection.
• Keep observational events non-reconstructing unless their contract explicitly says otherwise.
• Add replay tests for normal sequences, duplicate events, invalid order, wrong base, unknown versions, and legacy events.

Acceptance criteria

• Replaying create-update-delete into a clean compatible runtime produces the defined terminal state without resurrection.
• Replaying the same event range twice is idempotent.
• Missing base, unknown schema version, invalid ordering, or identity mismatch fails before partial application or follows a documented atomic rollback rule.
• State-reconstructing events contain or reference every portable field required for their declared transition.
• Tombstone retention and compaction preconditions are documented and tested.
• Consumers can distinguish state-reconstructing events from observational events.

Constraints and non-goals

This issue does not implement concurrent writers, automatic merge policies, network delivery, enterprise approval workflows, autonomous promotion, or unbounded event retention.