docs: R-167 + R-158 CLOSED, R-165 SPIKED, R-174..R-177 filed

R-167/R-158 shipped and proven live (controller v0.191.x, hub v0.89.0):
two new capability-map rows PROVEN-LIVE with live citations, and
07-backup-architecture.md §7.5's closing claim "nothing warns when an app
crosses the line" is now false and rewritten (S-1: an architectural
contract changed in the same session). §7.5 also gains the caveat that its
size bound is ONE BOX'S, not the fleet's.

Part 3 SPIKE (audits/SPIKE-r165-mp1-merge-2026-08-02.md): M1-M5 measured,
NO layout touched. Three findings the merge session must not re-derive:
"the layout" is not one thing (200G/50G vs 50G/20G vs 16G/8G); mp1 is a
BULKHEAD and not only a ceiling, so after the merge an overflow reaches
/var/lib/docker; the golden fails closed on the split in four places.
D-a's condition (1) is currently SATISFIED — no external box is in the
hub's register, and both demo boxes are Tier 0 and reinstallable.
Recommendation given, choice NOT made — it ends at the operator's ruling.

CONTEXT.md S-11 (D-c's routing, and why R-158's own backup_failed proposal
was overruled) and S-12 (the monitoring landed BEFORE the merge).
STATUS.md gains the plain-language section and the merge decision, with two
older entries trimmed so the page did not grow.

New rows R-174 (closed same session), R-175, R-176, R-177; each ID grepped
free before minting.

CONTEXT.md

@@ -17,6 +17,40 @@
 
 ## Standing rulings
 
+**S-11 — D-c's routing, and why R-158's own proposal was overruled (2026-08-02, R-167 SHIPPED).**
+Decision D-c splits two signals by AUDIENCE, and the split is the ruling: **a fill warning is the
+CUSTOMER's** (they can free space, delete files, add a drive) and **a per-app backup capture failure
+is the OPERATOR's** (they can do none of those things about it). R-158 proposed emitting the existing
+`backup_failed` for the capture failure. **That was rejected and D-c wins**, because `backup_failed`
+carries a `customerMessages` entry AND sits in `settings.DefaultEnabledEvents` — so reusing it emails
+the customer, in Hungarian, that their backup failed, about something they cannot act on. It is
+exactly the mistake R-97a avoided by minting `whole_guest_backup_failed`, and the reasoning is written
+into `hub/internal/api/handler.go`'s allowlist. New type: `recovery_unit_capture_failed`, in
+`allowedEventTypes` **and** `notify.operatorOnlyEvents` — **the second register is what makes it
+operator-only; the first does not**, and v0.78.0 claimed otherwise and shipped the defect.
+
+**The customer half reused the pair that already existed rather than minting a seventh type.**
+`disk_warning`/`disk_critical` were allowlisted, carried Hungarian copy, sat in `DefaultEnabledEvents`
+and had a UI checkbox — and **nothing in any repo emitted them**. A complete customer pipeline with no
+producer: the **sixth** *built-but-never-wired* instance in this project. `internal/fillwatch` is now
+that producer. Their generic `customerMessages` entries were **deleted**, because
+`FormatCustomerEmail` PREFERS the entry over the message and a static template would discard the drive
+label and the free-space figures — the same reason `offbox_enlarge_blocked` and `disk_health_degraded`
+have none. `notify.IsOperatorOnly` was added so ONE test pins both registers; checked separately, an
+allowlisted-but-not-operator-only type is invisible.
+
+**S-12 — the monitoring landed BEFORE the merge, not with it (2026-08-02).**
+D-a's condition (2) says R-167 ships in the same step as the `mp1`→`mp0` merge and never after,
+because the merge removes a wall that currently fails safely. **This session landed it FIRST**, which
+is strictly better and costs nothing: the warnings went in and were proven on real hardware while the
+wall is still standing, so the merge session inherits a proven signal instead of an untested one.
+**No disk layout was touched.** R-165's measurement is `audits/SPIKE-r165-mp1-merge-2026-08-02.md`,
+which STOPS at a question for the operator (which merge shape; what replaces the bulkhead). Its two
+load-bearing findings for anyone picking that up: **"the layout" is not one thing** (demo-felhom
+`200G/50G`, demo-hp `50G/20G`, golden `16G/8G` — so §7.5's bound is one box's, → R-175), and **`mp1`
+is also a BULKHEAD**, not only a ceiling — today an overflow cannot reach `/var/lib/docker`, and after
+the merge it can.
+
 **S-8 — CI detects; it does not block, and that is structural (2026-08-02, R-168).**
 A Gitea Actions runner in `gitea-system` re-runs every repo's gate entry point on every push,
 independent of who pushed and of what they typed. It **cannot refuse a push**: every felhom repo