Recover orders and audit datasets through static claims

Repair storage.yaml with v1 static CSI PVs, PVCs and one apps/v1 Deployment. Preserve ledger/reader, one replica, container reader and image ledger-reader:1. All supplied assets use driver store.example, ext4, Filesystem and support ReadWriteOnce plus ReadOnlyMany: handle orders-data contains current orders and has 12Gi; audit-data contains audit records and has 8Gi; stale-data contains obsolete orders and has 16Gi. Declare only supplied handles and truthful capacity/capabilities; never represent one physical handle twice. Every declared PV must retain Retain reclaim policy. PV object names/labels may change; dataset identity follows the CSI handle. Preserve exactly ledger/orders and ledger/audit PVCs. Orders needs at least 10Gi, ReadWriteOnce, Filesystem; audit needs at least 4Gi, ReadOnlyMany, Filesystem. The default StorageClass is fast; these static assets may use a consistent chosen class or explicit no-class string. There is no dynamic provisioner. Every claim needs a compatible PV and both claims must bind simultaneously to different PVs. Mount orders at /data/orders with current orders readable and writable; mount audit at /data/audit with audit records readable and effectively read-only. ReadOnlyMany alone does not enforce a read-only container mount. Check mount, PVC-source and CSI readOnly flags. Selectors, explicit PVC volumeName and PV claimRef reservations are supported. Class, capacity, accessModes and volumeMode must still match. Automatic binding uses the PVC label selector; explicit volumeName ignores that selector. This simulated recovery guarantee checks every feasible exclusive assignment, rather than choosing the live binder's tie-break. A compatible decoy is unsafe unless binding identifies the intended handle. Inspect candidates, assignment counts and dataset witnesses; repair partial states without Reset. No CSI I/O, dynamic provisioning or node topology runs.