RFC: define retention, erasure, and lifecycle policies

Feature description

Define retention, forgetting, archival, and physical erasure policies across Sources and context artifacts.

PowerContext should preserve its current explicit, revisioned Memory forget/retire behavior while adding production-grade lifecycle controls for Source observations, Memory, Experience, Skill, Handoff, Candidates, Receipts, audit records, and rebuildable projections.

Problem and proposed solution

Logical forgetting, lifecycle state, storage retention, external deletion, and legal/administrative erasure are different operations:

• logical forgetting removes content from normal retrieval without rewriting history;
• deprecation or retirement changes whether an Artifact is eligible for discovery or publication;
• archival changes default visibility but preserves durable history;
• retention purges bounded operational records after a policy window;
• physical erasure removes content that must no longer be retained, while preserving the minimum non-sensitive tombstone needed for referential integrity and audit.

The RFC should define:

• family-specific lifecycle states and allowed transitions;
• versioned retention policies by deployment, scope, family, and record class;
• precedence among explicit user action, external-system deletion, policy expiry, legal hold, and administrator erasure;
• preview/dry-run, authorization, approval, scheduling, retry, crash recovery, and completion receipts;
• whether derived Artifacts are retained, invalidated, redacted, or marked evidence-unavailable when a Source is erased;
• exact citation behavior after logical forgetting, archival, or physical erasure;
• cleanup of FTS/vector/graph projections, caches, blobs, temporary packages, and remote Receiver copies;
• safe compaction of append-only operational logs without rewriting immutable Artifact authority;
• redacted audit records that prove a lifecycle decision without retaining erased content.

Automatic importance decay should not silently delete or rewrite PowerContext history. Any future age/access-based policy must be explicit, reviewable, and independently configurable from retrieval ranking.

Acceptance criteria

• A user can explicitly forget and later reactivate eligible Memory without creating a new content version, preserving current semantics.
• Operators can preview a retention/erasure run with exact bounded counts and reasons before mutation.
• Policies are versioned, authorized, idempotent, resumable, and auditable across SQLite and OceanBase.
• Physical erasure removes authoritative content and every declared projection/copy while leaving only a content-free tombstone where references must remain valid.
• Exact citations to erased content resolve as a stable unavailable/erased state; they never fall through to a different Revision or latest.
• A parent Source lifecycle action does not silently cascade-delete derived Artifacts without the accepted policy and an impact report.
• Legal hold or equivalent policy prevents scheduled deletion and is visible in dry-run output.
• Logs, audit, and error responses never reproduce content selected for erasure.

Alternatives considered

• TTL columns on every table: does not define authority, cascade, citation, projection, or audit semantics.
• Delete all old Revisions: breaks lineage, exact citations, Handoff verification, and rollback.
• Use automatic Ebbinghaus-style decay as deletion policy: conflates relevance scoring with user intent, compliance, and durable history.
• Keep everything forever after logical retire: insufficient for storage limits, external deletion obligations, and physical erasure requests.

Additional context

Related: #1395 for authorization/audit, #1397 for Skill lifecycle, #1219 for scope organization, and #1321 for bounded Memory storage/latency.

• I am willing to contribute code, docs, or design feedback.