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>

workplans/AUDIT-WP-0008-tenancy-posture-alignment.md

@@ -337,7 +337,7 @@ does not wait on T01. Mark the message read on send.
 
 ```task
 id: AUDIT-WP-0008-T03
-status: todo
+status: done
 priority: high
 state_hub_task_id: "0003954e-5033-457f-b9aa-97efdefe9beb"
 ```
@@ -373,7 +373,7 @@ and the operator runbook. Raises E to 2 on both paths; update T01's declaration.
 
 ```task
 id: AUDIT-WP-0008-T05
-status: todo
+status: wait
 priority: medium
 state_hub_task_id: "30b56b30-e7eb-4873-aa7c-f4a3bf2fcb24"
 ```
@@ -385,7 +385,7 @@ per §19.3.
 
 ```task
 id: AUDIT-WP-0008-T06
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "ed58ca37-755b-4284-b1ac-2a02baaceb21"
 ```
@@ -404,8 +404,9 @@ duty, so the correction is ours to send unprompted or it will simply sit stale.
 
 ```task
 id: AUDIT-WP-0008-T07
-status: todo
+status: progress
 priority: high
+state_hub_task_id: "e972a8f7-e6ee-4522-bc76-fb69d71e5ed5"
 ```
 Reach **V1** on the availability axis, new in draft-8.
 
@@ -422,13 +423,21 @@ observed ~40s of unreadiness after a node reboot, without enumerating the
 dependency set or recording a measured recovery time as an exercise. Decision
 4.6.1 is explicit that a replica count or a status page is not evidence.
 
-Write the exercise procedure and the dependency enumeration here; the exercise
-itself runs against railiance01 and needs a live window.
+Delivered in `docs/availability-recovery.md`: the seven-dependency enumeration,
+five exercise scenarios with integrity as a pass condition, and the measurement
+rules. The exercise itself needs a live window on railiance01 and coordination
+with `user-engine`, since two scenarios are visible to the sender.
+
+One thing the enumeration settled: **V2 is not reachable from P1 as built.**
+`platform-pg` runs `instances: 1`, and Decision 4.6.1 makes V the minimum across
+synchronous providers — so no amount of replication on our Deployment raises it.
+V1 is the ceiling here, not merely the next step.
 
 ```task
 id: AUDIT-WP-0008-T08
-status: todo
+status: done
 priority: high
+state_hub_task_id: "50eed5e2-06d6-4bdc-913d-5a8cd41ce613"
 ```
 Disclose the shared-substrate retention coupling in our **provider** block, and
 notify `user-engine` under Decision 6.1.