Implement expiry-safe replay sets

[flyingrobots]

Outcome

Provide an expiry-safe replay-marker policy surface with atomic add-if-absent, digest-only durable metadata, exact successor evidence, and expiry-only release.

Dependencies

• Implement retention namespace generation transitions #19 retention generations
• Implement precise verification reports and corruption refusal #20 verification reports
• Implement deterministic GC planning and identity-preserving compaction #21 GC and compaction
• ADR: define retention-derived lifecycle surfaces #85 lifecycle-surface ADR

Invariant impact

A live marker must not disappear before its admitted expiry through remove, repair, capacity, LRU, stale-writer, recovery, or GC paths. Duplicate admission must return exact existing evidence or a typed conflict.

Acceptance criteria

• Marker identity is a typed domain-separated digest; plaintext security tokens never enter durable metadata or diagnostics.
• Add-if-absent is atomic against one exact generation and refuses stale writers.
• Expiry is supplied as validated policy evidence; the core owns no ambient clock.
• No public remove, repair, capacity, or LRU path can release a live marker.
• Release admits only a policy observation at or beyond expiry and publishes an exact successor.
• Restart and reconciliation preserve every unexpired marker through all documented crash prefixes.
• Model, concurrency, corruption, property, fuzz, and process-death tests cover premature-release attempts.
• Receipts distinguish newly admitted, already present, expired and released, stale, unavailable, and corrupt states.

Non-goals

• Authentication, authorization, or token validation.
• Storing plaintext markers.
• Sharing cache eviction mechanisms.
• Claiming wall-clock truth beyond caller-supplied evidence.