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.

documentation/architecture/07-backup-architecture.md

@@ -529,6 +529,28 @@ portable secrets in the unit. **That independence is bounded by app size**, and
 > Past that the unit cannot be captured, and the app falls back to Lane 2's operator-driven
 > whole-guest route.
 
+**AS OF 2026-08-02 SOMETHING NOW WARNS, AND THE ALERTING IS PART OF THIS CONTRACT (R-167 / R-158,
+decision D-c; controller v0.191.x + hub v0.89.0).** The last sentence of this section used to end
+"nothing warns when an app crosses the line". Two signals now exist and both are PROVEN-LIVE:
+
+- **To the CUSTOMER, before anything fails** — `internal/fillwatch` warns per FILESYSTEM (never per
+  app: one full disk holding ten apps would fire ten times) on **whichever trips first, used ≥ 85% or
+  free < 5 GiB**, critical at 95% / 2 GiB, clearing at 75% / 7 GiB. **Two terms, because a percentage
+  alone lies at both ends of the range this section itself documents:** 85% of a 20 G `mp1` leaves
+  3 G — less than one DB-backed app's unit — while 85% of a 4 TB drive leaves 600 G. It watches the
+  app-data volume, the system-data volume **and** every registered drive, which the previous
+  `health_degraded` signal did not. Edge-triggered against persisted state; the hub owns cooldown.
+- **To the OPERATOR, when a capture actually fails** — `recovery_unit_capture_failed`, per app, with
+  the target filesystem's used/free bytes at the moment of failure, so the *why* needs no login. It is
+  **operator-tier** (`notify.operatorOnlyEvents`) and deliberately not `backup_failed`: a customer can
+  take no action on a capture failure.
+
+**A caveat this section must carry, because the bound below depends on it.** The `mp0 50G / mp1 20G`
+table above is **demo-hp's** shape, not the fleet's — demo-felhom ships `mp0 200G / mp1 50G`, where
+the same bound is ≈ 49 GB / ≈ 24 GB, and the golden's own defaults are `16 G / 8 G` before provision
+grows them. **The bound below is a FUNCTION of `mp1`, not a constant.** Measured 2026-08-02,
+`audits/SPIKE-r165-mp1-merge-2026-08-02.md` M1; correcting the numbers throughout is **R-175**.
+
 Two things are deliberately **not** recorded here. **The sizing ratio is the operator's ruling**
 (**R-163**) — this section states the constraint, not a number. And **the same-device placement is
 intended, not a defect**: a driveless app's unit sits on the same SSD as its volumes, but Tier-2's