R-85: demo-felhom restore-test PASSED — rotation proven on BOTH boxes; correct a bad estimate

The unattended offsite restore-test on demo-felhom passed: 14.46 GB archive,
duration_s=635.07 (10m35s), then it rotated to the local tier. Persisted state
confirms the credit: {"felhom-pbs": "2026-07-27T06:14:42Z"}.

CORRECTION: I estimated ~2 hours for this restore. It took 10m35s. I derived
the estimate from a download rate measured during the FAILED attempt, which was
running under contention; the real link does ~1.4 GB/min. I then used that wrong
figure to raise a design concern — that the heavy-op gate would block backups
for hours on this box — which at 10 minutes largely evaporates. An estimate
extrapolated from a degraded measurement is not a measurement.

The SPEC's closing risk note is corrected in place, with the original left
visible for the lesson.

documentation/backlog/SPEC-r85-phase4-5-2026-07-26.md

@@ -182,6 +182,13 @@ the observation window was too short, not an implication of coverage.
 
 ### One risk to weigh before 5.2 lands on demo-felhom
 
+> **RESOLVED 2026-07-27 — the risk below was based on a bad estimate and is largely void. Kept for
+> the lesson.** The actual unattended offsite restore-test on demo-felhom took **10m35s**
+> (`duration_s=635.07`) for its 14.46 GB archive — ~1.4 GB/min, not the ~125 MB/min I extrapolated.
+> That rate came from the *failed* attempt, which ran under contention. **An estimate extrapolated
+> from a degraded measurement is not a measurement**, and I used it to raise a design concern that
+> did not exist.
+
 Its offsite archive is **14.46 GB**. At the ~125 MB/min restore rate measured on that box, an
 unattended offsite restore-test there is a **~2-hour** operation that will now run roughly every
 other day, holding the heavy-operation gate throughout and so deferring backups behind it.