docs: README status was stale by a whole phase; record the R-STATE-03 decision

The Status section still said phases 0-6 were deployed on the DEV cluster and
that Phase 7 was not open with clusters/prod 'a design-only overlay'. Dev was
decommissioned on 2026-09-12 and prod has been the live cluster serving the
apex since. It also claimed 36/51 requirements covered with a safety-critical
gap, and that Velero was blocked on OQ-BKP.

Now states Phase 7 as open with its three exit criteria and which one is
actually outstanding; corrects the node inventory from the Proxmox dev IPs to
the bare-metal prod nodes; records Velero as unblocked to R2; and adds the
distinction the old text elided — coverage (51/51) is not proof (PROVEN: 0),
because the only dr-restore and node-loss proofs were recorded on a cluster
that no longer exists, against MinIO rather than R2.

Also records the owner's decision that Velero+kopia to R2 is the accepted
volume backup, with no Longhorn backup target, and that Longhorn config
belongs in source.

Co-Authored-By: Claude Opus 5 <[email protected]>

DECISIONS-LOG.md

@@ -3629,3 +3629,28 @@ never applied. Configuration was present in almost every case.
   folders on disk.
 - Deleting the orphaned kopia blobs from the two R2-tagging failures.
 - The stale workstation dnsmasq override (`sudo rm` — blocks local name resolution).
+
+---
+
+## 2026-09-13 — DECIDED (owner): Velero+kopia to R2 IS the volume backup; no Longhorn backup target
+
+I had escalated this as a blocker for the Phase 7 DR drill: `settings.longhorn.io/backup-target` does
+not exist on prod (a WS-STORAGE Phase-4 leftover), so there is no Longhorn-native volume backup and
+no second restore path.
+
+**Owner's decision: that is fine.** Volume data is already protected by Velero + kopia to Cloudflare
+R2, and that is accepted as the practical backup for R-STATE-03. No Longhorn backup target will be
+configured. Corollary the owner also stated: **Longhorn configuration belongs in source**, which is
+where it now lives — the I/O caps and `nodeDrainPolicy` landed in `platform/longhorn/helmrelease.yaml`
+`defaultSettings` rather than as live-only settings (see the entry above).
+
+**What this makes true and what it does not.** The restore path is single: Velero's kopia file-system
+backup through the node-agent to R2. That is a genuine off-cluster copy — the `dr-restore` test proves
+it by asserting the restored PVC binds a *different* PersistentVolume than the original, so an
+in-cluster survival cannot masquerade as a restore. What it is not is redundant: a failure in Velero's
+R2 path has no Longhorn-side fallback, and the R2 target has already shown one incompatibility this
+month (the `velero-plugin-for-aws` `x-amz-tagging` 501, fixed by pinning the plugin). Worth revisiting
+only if that path proves unreliable, not on principle.
+
+Consequence for the roadmap: the DR drill is unblocked and Phase 7's remaining exit criterion is
+simply to run it on prod and record the proof.