Recovery cancellation bypasses Store and crashes after privacy fencing on Postgres #23761

Shared old/new recovery conformance reproduces a cancellation gap on current main (4f52db8b3b), with synthetic owners only. No production observations or private data are involved.

After a held unit has a prepared recovery intent, add an account-deletion marker either before recovery or during audio download. RecoveryStore.prepare/start correctly raises BatchPrivacyBlocked. The coordinator catches it and calls cancel_fenced_recovery, which unconditionally uses store.client.collection(...). SimStore.client is None and PostgresStore has no client attribute, so the caller raises AttributeError (NoneType.collection on sim, missing PostgresStore.client on Postgres) and the durable intent is not marked cancelled. Firestore completes both cases.

Reproduction uses backend/tests/integration/test_recovery_admission_conformance.py::test_pl072_account_deletion_cancels_recovery_before_paid_work_or_upload in #23763. Before marking expected failures, the complete strict matrix ran 23 passed / 4 failed / zero skips, on real loopback Firestore and real local Postgres plus the simulator. The four failures are both deletion phases on sim/Postgres; all Firestore cases pass. Production modules are unchanged from the main baseline.

Required invariant (PL-072): deletion cancels a prepared/running recovery before another paid call or result upload; duplicate deliveries remain cancelled and do no provider/artifact IO; unrelated owners keep progressing. Preserve owner, privacy-generation and exact-intent fences. Physical privacy erasure is a separate gate.

Recommendation: A supplies a bounded, revocation-only cancellation operation on the shared Store surface; C uses it instead of an unconditional Firestore-client write. Do not attach a fake Firestore client to Postgres or permit ordinary fenced writes. The conformance PR records strict expected failures limited to these two backends and the reproduced AttributeError; they do not count as completed parity.

Action class: local code/test and issue publication. No merge, deploy, production data access, paid retry or configuration change.