docs: R-172 CLOSED (hub v0.88.0), R-173 filed, session report

R-172's root cause was not tuning — the WAL/busy_timeout pragmas had never been
applied, because the DSN used mattn/go-sqlite3 syntax against modernc.org/sqlite,
which ignores unknown parameters without an error. Recorded that way so nobody
re-reads it as "SQLite was slow".

R-173 NEW: while establishing who copies hub.db for the WAL change, found
pvc/hub-data labelled recurring-job-group.longhorn.io/default: disabled, with
backup-daily and backup-weekly the only recurring jobs and both on the default
group — so the hub database has no volume-level backup, and it holds every box's
break-glass root password plus the escrow custody records. Filed, not fixed:
whether the exclusion is deliberate is an operator question.

The session report is REPORT-r172-hub-wal.md, not REPORT.md, per the
parallel-session rule — REPORT.md belongs to the controller session that ran
immediately before this one.

It also records, plainly, that a 60-concurrent load test I ran OOM-killed the hub
pod three times against a 256Mi limit. Not the WAL change, and not a test I
should have run against a Tier-2 box; the unit tests already proved the property.

STATUS.md

@@ -66,6 +66,15 @@ It notices, quickly, and tells you. *(R-29, R-161, R-168, R-169)*
 
 ## Changed since last update
 
+- **2026-08-02** — The false "host offline" warning is fixed, and the cause was not what it looked
+  like. The hub's database was supposed to be in a mode where reading a page cannot block a machine's
+  status update — the code said so, but a one-word syntax difference meant the setting had **never
+  taken effect**, for the hub's whole life. So opening an operator page could make a machine's report
+  fail; two failures in a row crossed the half-hour threshold and sent you an alert about a machine
+  that was up and healthy. It had already done that twice that day. Now genuinely fixed and verified
+  live. **Also found while checking it: the hub's own database is not in any automatic backup** — it
+  holds every machine's emergency password and the escrow records. Filed, not yet fixed.
+
 - **2026-08-02** — Boot recovery finished. Both halves of the power-cut problem are closed: the
   machine records what the customer asked for, and it now waits for the system to finish starting
   before deciding what is missing. Six hard resets in a row, everything back every time. A hole the