Drill new household: phase-2 night evidence; R-726 (orphaned off-site repo on a reused customer), R-727 (restore test picks a previous box's archive)

Secret scan: 0 hits over 55 files, positive control 1.

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

documentation/backlog/OPEN-ITEMS.md

@@ -837,6 +837,8 @@ class (an image `VOLUME` at an unmounted path) is still live — `immich-server`
 | **R-723** | **[P3-LOW] A fresh box sends the operator two mails on day one that describe nothing wrong.** MEASURED 2026-09-29: `Operator email sent for tester-1/node_recovered` 2 s after the new box's first controller report (the customer's previous box had been silent 12 days — the new box is not a recovery); and `backup_tier_skipped (warning) — Whole-guest backup tier felhom-pbs skipped: its storage does not exist on the host (never provisioned or removed)` → operator mail at 19:27 UTC, 7 min after enrolment, because the first whole-guest run fired before the off-site tier's descriptor arrived (applied ~19:35 UTC, backed up fine at 19:37). Operator-only, so no household is alarmed, but an operator learns to ignore both. **Fix direction:** `node_recovered` not for a host enrolled < N min ago; the skipped tier inside the first hour after enrolment is `info`, not a mailed warning. | **READY — rank P3-LOW; owner: CC** |
 | **R-724** | **[P3-LOW] The status pages disagree with each other in small ways a household notices.** MEASURED 2026-09-29 on a fresh box: Beállítások reads „Mentés ütemezés 02:30 / 03:00" while Biztonsági mentés says 02:30 / 03:30 / 04:15 / 04:30–08:30; Beállítások shows a raw `2026-09-29T19:22:30Z`; its „Helyi cím (LAN)" and „Átjáró" read „nem állapítható meg" on the page the household is asked to read out for remote help; the backups overview still says „Következő mentés — 0 órája" (the age of the LAST run, under the word "next" — noted 2026-09-14, never filed); the dashboard shows the backup at 19:33 where the backup pages say 21:33 (R-500, still reproducing). | **READY — rank P3-LOW; owner: CC** |
 | **R-725** | **[P3-LOW] Small copy slips on the first-hour path.** MEASURED 2026-09-29: the self-bind PAGE says the passphrase was received „a beállításkor" while the mail and console say „a Felhom üzemeltetőjétől" (R-497 unified the mail and console, not the page); the recovery-code wizard addresses the household formally („Írja fel", „adja meg") while every other screen says „te"; the console's linked banner ends „a doboz össze van kötve. V" (a stray glyph); a gated app answers a phone app's API call with English JSON „this app is waiting for its first setup" (the browser gets the Hungarian gate page). | **READY — rank P3-LOW; owner: CC** |
+| **R-726** | **[P2-MEDIUM] A new box for a customer who had one before makes NO off-site copy on night one: the old repository is found orphaned, and the fix is a button nobody pointed the household to.** MEASURED 2026-09-30 00:15 UTC on the new-household drill box (`tester-1`, whose previous box was deleted 2026-09-17): `[offbox] offsite repo ORPHANED — remote holds backups written under a previous, no-longer-available key; runs will skip until reset` → `offbox_repo_orphaned` (warning) to the household's timeline and an operator mail; `offsite-integrity` then checked nothing. The household's page is honest („A távoli tároló másik kulccsal készült mentéseket tartalmaz … Új távoli mentés indítása…", old history set aside, never deleted), but the evening before, the recovery-code ceremony and the off-site page raised nothing, and the guide does not mention it. The hub re-issued the off-site credentials on re-enroll by itself; it could have known the repository would orphan. Customer data was never at risk (the old repository is untouched); the household simply has no off-site copy until someone presses the button. **Fix direction:** offer the reset at the recovery-code ceremony when the repository already holds another key's snapshots, or the hub's re-enroll re-issue sets the old history aside the same way (it is the same move-aside), and the guide says so. | **READY — rank P2-MEDIUM; owner: CC (design first) / operator (which)** |
+| **R-727** | **[P2-MEDIUM] The whole-guest restore test picks a PREVIOUS box's archive, fails on its key, and the household sees a bare ✗ labelled with the wrong tier.** MEASURED 2026-09-30 01:52 UTC on the drill box: the agent's restore test chose `felhom-pbs:backup/ct/9201/2026-09-16T21:59:54Z` („newest settled archive … has not been proven") — written by a drill box of 2026-09-16, still in the customer's ep0 namespace next to tonight's own `2026-09-29T19:37:07Z` — and failed `wrong key - unable to verify signature since manifest's key 6b:ca:5f:3f… does not match provided key de:51:7a:18…`. One operator mail (`restore_test_failed`); the hub then re-logged the stored failure at every 15-minute report for 5 hours. The household's backups page read „✗ Visszaállítás ellenőrizve 2026-09-30 03:52 — Helyi tároló (local)" — the local tier had not failed; the pbs tier had, and the page says neither which nor why. Root: host delete leaves the old box's archives in the namespace (R-526's shape). **Fix direction:** the restore test skips (and reports as foreign) archives whose key fingerprint is not this host's; the page names the tier that failed. | **READY — rank P2-MEDIUM; owner: CC** |
 
 <!-- DUE-CHECKS-BEGIN — machine-readable. Parsed by scripts/due_checks_gate.py.
      One row per dated check. The R-number must have a row above. Dates are UTC.