Implement AUDIT-WP-0008 T03, T06, T07, T08.

T08 fixes two defects in our own declaration. provider.R.available quoted a
30-day horizon audit-core does not solely control: at P1 the erasure horizon is
the instance maximum across co-residents, so a co-resident declaring longer
extends what a sender's records remain recoverable for, silently. Decision 4.5.4
names this for tiers; it applies to a provider quoting a number too, and the
provider block now says so. And user-engine, the only consumer, was notified
under Decision 6.1 -- what we declared, that E4 and R4 are unreachable here, and
that the retention number is a floor rather than a ceiling.

T03 writes docs/erasure-and-audit.md: the fact/payload split, why shreddability
is not retrofittable onto a chain committing to cleartext, and why the retained
hash is a confirmation oracle over low-entropy audit records. The framework half
was already resolved as Decision 4.5.3, so what remains is our own position. The
legal basis for retaining audit facts is routed to risk-nexus, open and visible.

T06 closes the review loop with net-kingdom: five findings adopted, declaration
validates clean, and the E line will go stale on an upgrade that Decision 6.1
deliberately does not require anyone to announce.

T07 enumerates the seven dependencies on the accept path and specifies five
recovery scenarios with integrity as a pass condition. It settled one thing: V2
is not reachable from P1 as built, since platform-pg runs instances 1 and
Decision 4.6.1 makes V the minimum across synchronous providers. V1 is the
ceiling here, not the next step. The exercise needs a live window.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tenancy.yaml

@@ -106,7 +106,11 @@ tenancy:
     V: >-
       No exercise establishes restart recovery for the complete audit path.
       V1 is the target; replica count or Kubernetes restart policy is not
-      treated as evidence.
+      treated as evidence. Dependencies enumerated and the exercise specified in
+      docs/availability-recovery.md (AUDIT-WP-0008-T07); the exercise itself
+      awaits a live window on railiance01. V2 is not reachable at P1 as built:
+      platform-pg runs instances 1, and Decision 4.6.1 makes V the minimum across
+      synchronous providers, so V1 is the ceiling here rather than the next step.
 
 provider:
   capability: operations.audit
@@ -126,6 +130,21 @@ provider:
       maximum: 2
       conditions:
         - "R4 is unreachable while the integrity chain commits to cleartext hashes."
+        - >-
+          The 30-day horizon is declared but NOT solely ours to hold. audit-core
+          is at P1, and on shared substrate the erasure horizon is the instance
+          maximum across co-residents (§4.5), not the value this consumer
+          declares. A co-resident on platform-pg declaring a longer window
+          extends what a sender's audit records remain recoverable for, without
+          any change here and without notice to the sender. Decision 4.5.4 names
+          this as why a bare R2 is insufficient for a retention promise; we are
+          not a tier, but we are a provider quoting a number we do not control
+          alone, and a sender relying on 30 days should read it as a floor on
+          our side and a platform-derived maximum in practice.
+        - >-
+          A sender needing a horizon it can actually rely on needs audit-core at
+          P2. That is the §4.5 retention trigger and it is recorded in
+          gap.retention_placement with a 2026-12-31 review.
       evidence:
         - "rapp-postgres/consumers/audit-core.yaml"
         - "audit_core/interface.py"