docs(ep0): relocate the felhom-offsite PBS datastore onto the 100 GB volume

Supervised runbook execution. No code change, no version bump.

felhom-offsite moved from ep0's 40 GB root disk (/srv/pbs-felhom) to a
dedicated 100 GB Hetzner Cloud Volume (/mnt/pbs-datastore, ext4 -m 0,
by-id fstab, relatime). Datastore NAME unchanged, so the PBS-DR
descriptors, per-box storage ids, ACLs and namespaces are untouched.

Capacity: 37.2 GB -> 98 GB total, 28.9% -> 13% used, headroom to the 80%
warn 19 GB -> ~65 GB. This CLEARS the R-82 Phase 0 P0.3 STOP. Per-tenant
encryption still precludes cross-customer dedup, so the slope is
unchanged - the volume buys runway, not a better cost model.

Verified: byte totals and chunk counts identical (9748), 7/7 snapshots
across all three namespaces, backup:backup ownership, clean itemised
dry-run, full verify job TASK OK with 0 errors, and a restore round-trip
(source_tier pbs, pass true, mount_parity ok, clean teardown).

Nothing deleted - the original 13 GB stays at /srv/pbs-felhom as the
rollback until a new weekly backup lands. GC deliberately not run.

Three findings recorded:
- the `scratch` datastore points at a non-existent path (pre-existing;
  now logs ENOENT every start) - operator decision
- the runbook's S6 guard test proves the wrong proposition:
  RequiresMountsFor re-mounts rather than refusing, so the test only
  bites when the device is genuinely unavailable (re-run that way, and
  the refusal was observed) - amendment recommended
- S11: storage box u629193 has no live backup path, BUT ep0 carries an
  enabled sshfs mount unit against it that must be removed before the
  box is deleted

Deviations: the volume arrived pre-formatted and mounted; S8 ran on
demo-felhom rather than demo-hp (no SSH key for demo-hp); the window was
contended by a stale in-memory 10-minute restore-test cadence whose
config had already been reverted on disk.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018ARoadHBf8rHoscfiqeVZn

documentation/audits/SPIKE-r82-phase0-2026-07-26.md

@@ -139,7 +139,19 @@ change, deliberately **not** made here.
 
 ---
 
-## P0.3 — Capacity: 🛑 STOP
+## P0.3 — Capacity: 🛑 STOP → 🟢 **CLEARED 2026-07-27**
+
+> **Resolution (2026-07-27).** The datastore was moved off ep0's 40 GB root disk onto a dedicated
+> **100 GB Hetzner Cloud Volume**. Total **37.2 GB → 98 GB**; used **28.9 % → 13 %**; headroom to the
+> 80 % warn **19 GB → ≈65 GB**. The "80 % at roughly the second additional customer" projection below
+> becomes **roughly the seventh to thirteenth**. Method, verification and the restore round-trip that
+> re-cleared the tier: `runbooks/RUNBOOK-ep0-datastore-volume-2026-07-27.md`.
+>
+> **The dedup fact below is unchanged and still governs the slope** — per-tenant encryption still
+> means no cross-customer dedup. The volume bought runway, not a better cost model. The weekly
+> incremental size remains **unmeasured**.
+
+**The analysis below is the original 2026-07-26 record, retained as written.**
 
 ### Measured