R-192: offsite_delivery_stuck states the opposite of what it measured

demo-hp has been emailing daily since 2026-08-03 06:12 UTC that '500 reports
since carry no offbox target — the credential is likely burned'. Measured against
the hub's own data: all 500 of those reports DO carry one. The credential was
consumed 2026-07-23 and applied successfully; the controller reported an offsite
object continuously until 2026-08-03 05:59:21, then it vanished at 06:12:19 and
has been absent for 108 reports. A regressed apply, not a burn.

Two defects. maybeEmitStuck builds its message from ReportsSinceConsume while
hardcoding 'carry no offbox target' and never consults OffsiteReportsSinceConsume,
so the recommended action targets a failure that did not occur. And maybeHeal
refuses SILENTLY on exactly that field ('regressed-apply shape -> operator's
call', a bare return), so there is a daily email with the wrong story, no heal,
and nothing saying why the heal declined.

The underlying condition is real: that box currently has no off-site copy of its
customer app data, since 08:12 CEST on 2026-08-03. What removed it is not
established.

STATUS.md

@@ -20,6 +20,13 @@ Proven end to end on real hardware.
 
 ## What's broken
 
+- **One demo machine has no off-site copy of its app data, and has not since yesterday morning.** The
+  second demo machine (`demo-hp`) stopped reporting an off-site backup at 08:12 on 3 August and has
+  not reported one in 108 check-ins since. The daily email you are getting about it is right that
+  something is wrong, but **its explanation is wrong** — it says the password was never applied, when
+  in fact it was applied on 23 July and then stopped working eleven days later. The automatic repair
+  declines, correctly, because it can see it is a different problem — but says nothing about why.
+  *(R-192)*
 - **The weekly off-site backup reports FAILED although it worked.** It uploads correctly and then
   trips on a tidy-up step it is deliberately not allowed to perform, so the job ends in an error and
   you get an email. The backup itself is safe and on the endpoint. Both demo machines do it; one