feat(escrow): v0.138.0 — "awaiting hub confirmation" waiting state

After a completed escrow ceremony the Távoli mentés page showed the yellow
"Helyreállítási kód szükséges" card for ~15 min until the next hub-report ACK
flipped pending→escrowed. Phase-0 diagnosis (read-only) = verdict A (report-cycle
lag), already resolved on the demo box (escrow_state:"escrowed"); hub Hypothesis B
verified false (SaveHostEscrow ON CONFLICT already clears stale_at on upload) → no
hub change.

- settings.OffboxTarget.CeremonyCompletedAt: stamped on the recovery-code claim,
  zeroed on the auto-confirmer Flip + the deprecated manual confirm; persisted.
- web/handlers.go: offboxCeremonyWaitState + escrowCeremonyGraceWindow (35m).
- backups_remote.html: info "megerősítésre vár, legfeljebb 15 perc" card → warn
  "a megerősítés nem érkezett meg" past the window. Existing branches untouched.
- backups_escrow.html: "Mi történik ezután?" note on the wizard's final step.
- Test web/escrow_wait_state_test.go (truth table + red-proof recorded in REPORT).

No scheduler/agent/hub/endpoint changes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017qDiBqKKQ5vPB5fXBqu7Kp

CHANGELOG.md

@@ -1,5 +1,32 @@
 ## Changelog
 
+### v0.138.0 — escrow "awaiting hub confirmation" waiting state (2026-07-16)
+
+Closes the customer-zero (N100) UX gap: after a completed escrow ceremony the Távoli mentés page kept
+showing the yellow **"Helyreállítási kód szükséges"** card for ~15 minutes, until the next hub-report
+ACK flipped `pending→escrowed`. **Phase-0 diagnosis (read-only) = verdict A (report-cycle lag)**: on the
+demo box the ceremony completed `16:13:39` and the very next `hub-report` ACK at `16:27:58` auto-confirmed
+via hash-match (`d517ce7f…`), `escrow_state:"escrowed"` — nothing was broken; the wait simply had no UI
+feedback. (Hub stale-clear-on-upload — Hypothesis B — was verified to already exist: `SaveHostEscrow`'s
+`ON CONFLICT` sets `stale_at = NULL`, so **no hub change was needed or made**.)
+
+- **`settings.OffboxTarget.CeremonyCompletedAt`** (new, `ceremony_completed_at`, RFC3339) — stamped on a
+  successful recovery-code **claim** (`web/escrow_handlers.go`, only while still pending; best-effort, a
+  stamp failure never fails the claim) and **zeroed** on the `pending→escrowed` flip (the auto-confirmer
+  `Flip` closure in `cmd/controller/main.go` + the deprecated manual confirm in `web/offbox_handlers.go`).
+  Persisted → survives a controller restart mid-wait.
+- **`web/handlers.go` `offboxCeremonyWaitState` + `escrowCeremonyGraceWindow` (35m):** classifies the
+  wait — *awaiting* (stamped, within the window) vs *timed out* (stamped, past two report cycles + slack).
+  Both fall back to the plain pending CTA when escrowed, unstamped, or the stamp is unparseable.
+- **`backups_remote.html`:** one new escrow-card branch ahead of the existing chain — an **info (blue)**
+  "Helyreállítási kód létrehozva … megerősítésre vár, legfeljebb 15 perc" card, degrading to a **warn**
+  "A megerősítés nem érkezett meg …" + re-ceremony CTA past the window. The existing pending/stale
+  (Scenario F)/escrowed branches are untouched.
+- **`backups_escrow.html`:** the wizard's final "Befejezés" step gains a **"Mi történik ezután?"** note so
+  the customer expects the interim card on the page they land on.
+- Test: `web/escrow_wait_state_test.go` (truth table + mutual-exclusion invariant; red-proof recorded in
+  REPORT). No scheduler/agent/endpoint changes.
+
 ### v0.137.0 — empty-email notification save guard (data-loss fix) (2026-07-15)
 
 Fixes a silent alert-delivery wipe demonstrated on the demo customer on 2026-07-15: saving the