docs(adr): add retention state machine for erasure and legal hold

[irelia0nerf]

Summary

Adds ADR-0008 defining the retention state machine for erasure, legal hold and regulatory-retention conflicts.

Decision Scope

• Keeps immutable evidence as the integrity root, not the erasure control plane.
• Requires separation between immutable evidence, mutable key/retention control, encrypted payload storage and analytical indexes.
• Defines the minimum retention lifecycle for erasure requests, retention expiry, legal hold, regulatory review and key destruction.
• Adds Airlock, Legal Precedence and Key Destruction Semantics rules.
• Updates adr/README.md to list ADR-0008.

Validation

This ADR requires implementations to prove that:

• immutable evidence contains no raw sensitive payloads, plaintext PII, content keys, wrapped content keys or reversible lookup tables;
• immutable commits have passed quarantine validation;
• legal hold blocks key destruction and payload purge;
• regulatory retention blocks destruction when required by policy;
• erasure requests create signed retention decisions before destruction;
• scheduled key destruction is not reported as terminal destruction;
• analytical indexes remain rebuildable from state, receipts and sealed evidence.

[gemini-code-assist]

Code Review

This pull request introduces ADR-0008, which defines a retention state machine for managing data erasure, legal holds, and regulatory retention. The architecture separates the immutable evidence store from a mutable key and retention plane to support privacy requirements like GDPR while maintaining audit integrity. Review feedback highlights the need for high-durability controls for the key store to prevent accidental data loss, the addition of transition paths for when legal holds are lifted, and the use of deterministic schema-level validation for the airlock rule. There is also a suggestion to clarify terminology regarding operator inspection controls.

[gemini-code-assist]

The decision to move content keys to a separate mutable plane makes this component a critical dependency for data accessibility. If the key store is lost or corrupted, all associated evidence becomes permanently unrecoverable (unintended cryptographic erasure). Given the high-assurance requirements of the evidence store, the ADR should explicitly require the key plane to have equivalent durability and recovery controls (RPO/RTO) to prevent accidental data loss.

[gemini-code-assist]

The state machine defines states for when shredding is blocked by legal hold or regulatory retention, but it lacks a transition path for when these blocks are lifted. Without an explicit 'Hold Released' or 'Re-evaluation' state, records may remain stuck in a blocked state indefinitely after the legal necessity has passed. Consider clarifying the return path to an active or shred-ready state once a hold is removed.

[gemini-code-assist]

'Verify absence' can be interpreted as non-deterministic scanning (DLP). Given the requirements in ADR-0001 for schema-level restrictions, it would be clearer to specify that the airlock enforces these constraints via schema validation to ensure deterministic rejection of non-compliant artifacts.

Suggested change

	The airlock must verify absence of raw sensitive payloads, plaintext PII, content keys, wrapped content keys and reversible lookup tables.
	The airlock must enforce schema-level rejection of raw sensitive payloads, plaintext PII, content keys, wrapped content keys and reversible lookup tables.

[gemini-code-assist]

'Operator explanation' appears to be a typo or an ambiguous term in this context. Based on the requirement to return state and reason codes, 'Operator inspection' or 'Status query' would be more descriptive of the intended administrative control.

Suggested change

	- Operator explanation must return current state, reason code, policy hash, authority reference and pending action.
	- Operator inspection must return current state, reason code, policy hash, authority reference and pending action.