docs: R-191 closed, R-190 mitigation shipped (mechanism open), R-194 filed

R-191: the gate was run first and it mattered — ep0's prune jobs have run daily
since 2026-07-27 (18 tasks, all OK). THREE of my own queries said the opposite and
all three were broken instruments (worker-type vs worker_type, prune vs prunejob,
proxmox-backup vs proxmox-backup-proxy); acting on any would have disabled the only
pruning attempt while reporting that nothing prunes.

R-190: the row now reflects the MITIGATION, not the cause, and says so. Includes
that v0.124.0's transition record failed in production while every unit test
passed, and Part 3's single pass — the token-rotation class is real and documented
in our own installer but does not fit this box (same token still authenticates, the
other three grants survived, no installer run evidenced); ruled out on this box, not
fleet-wide.

R-194: PVE caches permissions (~40s and ~16min measured), so a single permission
read is a lagging indicator and may explain when R-190's refusal surfaced.

07-backup-architecture: the offsite retention row was RIGHT and the configuration
disagreed with it — noted, since a doc that states a contract does not enforce it.

CONTEXT.md

@@ -17,6 +17,33 @@
 
 ## Standing rulings
 
+**S-24 — offsite retention is ep0's, and the box asks for none (2026-08-04, R-191; installer 1.25.0).**
+R-89 moved offsite pruning server-side and box tokens stay write-only. The 2026-07-26 "two weeks"
+ruling was not reversed — **where it is ENFORCED moved, and the installer's `keep_last: 2` did not
+follow**, so every weekly run uploaded fine and then failed the job on a refused prune. The offsite
+tier now writes `keep_last: 0`, which the agent's existing guard already reads as *never prune from
+the box*; the local tier is untouched. A gate asserts it. **Before switching it off, ep0 was read:**
+both namespaces have a prune job at 03:30 keep-last 2 that has run daily since 2026-07-27 (18 tasks,
+all OK). **If that ever stops, `keep_last: 0` is unbounded growth** — check ep0's prune jobs before
+assuming the offsite tier is retained.
+
+**S-25 — a lost storage grant repairs itself, and the repair is REPORTED (2026-08-04, R-190; agent
+v0.124.1).** On a missing grant the agent runs the existing root wrapper (`felhom-backup-target-apply
+grant <id>`, already sudoers-permitted for any id) and re-reads once — the pbsdr R-22 shape. Bounded
+at one attempt per tier per hour.
+
+*The record is the point, and getting it wrong is easy.* A repair that leaves only `ok` behind
+destroys the only evidence a permission vanished. v0.124.0 reported degraded for "one cycle" and
+**that failed in production while every unit test passed**: `probeAll` is called independently by the
+self-check log and by the collector, the repairing call was the log's, and the host-report three
+seconds later sent `ok`. The fix is a latch on **time** (20 min > the 900 s report interval), so at
+least one report must carry it. The explanation rides `Feature`, because that is the field the hub
+interpolates into the operator's e-mail — `Reason` does not travel. **Nothing new was built:** the
+hub's existing ok→degraded→ok edge is the channel.
+
+*Caveat measured live:* **PVE caches permissions** (~40 s and ~16 min observed), so detection lags the
+loss and a single permission read is a lagging indicator → R-194.
+
 **S-23 — the host (on-box) whole-guest tier is restore-PROVEN, unattended, on both demo boxes
 (2026-08-04). Scope: those two boxes, not the fleet.**