SPIKE R-95: the safety net cannot be seen from the box - and that RAISES the urgency

READ-ONLY STUDY. No code, no version, no image, no golden. No delete verb was issued against any
live store. ep0, DooPlex and Peti's box were not touched at all.

Q1 FIRST, AND IT DID NOT GO THE EXPECTED WAY. The brief supposed a working seven-day snapshot net
might bound the worst case. Measured on BOTH boxes over their own SFTP credential, with a positive
and a negative control on each: NO .snapshots is visible to either sub-account - not in the account
home, not inside the repo - and the account is jailed at /. Either none exist or a sub-account
cannot see them, and the second is not a reprieve: a snapshot the box cannot see is one the box
cannot restore from, so recovery would be an operator act at the Hetzner panel.

The register's claim rests on nothing that was checked. The row has NO R-number, so nothing can cite
it; its "confirm tomorrow" was 2026-07-27, 36 days ago; and the DUE-CHECKS block built for exactly
this (R-341) is EMPTY. R-95's word "ARMED" is withdrawn pending R-429. The confirming field is a
Hetzner API field, so this spike STOPPED at the section 11-D fence and left it for Viktor - ten
minutes in the panel, and it re-ranks everything.

Q2: TEN verbs, not nine. `check` was missing from the brief's list; `dump` is not a verb (it is a
progress phase constant) and was withdrawn. There are TWO `forget --prune` sites - offbox.go:1388
AND offbox.go:1759 - and disarming one without the other reproduces R-191 exactly.

Q3 (documented, from our own API mirror): AccessSettings has five booleans and `readonly` is the
only permission axis. No append-only. So the PBS shape does NOT transfer - PBS is a server that can
refuse; a Storage Box is a filesystem that runs nothing.

Q5 (measured, faithful append-only model, both controls passed first): withdrawing delete does NOT
wedge the store - restic treats a dead owner's lock as stale and proceeds. The constraint everyone
feared is not the blocker. But `unlock --remove-all` printed "successfully removed locks" while the
lock was still there, and resticStep's crash-lock self-heal is built on that call - R-430.

Q6 (measured, with a control): restic 0.14.0 DOES speak rest:. Append-only is a rest-server flag,
not a restic one.

Q7 (measured): detection is nearly free. snapshot_count already reaches the hub and the hub APPENDS
reports, so the history to compare against is already on disk.

RECOMMENDATION: answer Q1 today (Viktor, ten minutes), then build detection, then move retention off
the box. Defer the transport change until Q1 is answered.

Register: OPEN 179 -> 181. Filed R-429, R-430; R-95 updated and kept OPEN. 07 row 10's status is
deliberately UNCHANGED.

STATUS.md

@@ -18,7 +18,7 @@ not an evening's work.**
 *This section is allowed to be longer than one screen, and each item says what happens if you do
 nothing.*
 
-1. **Nothing is waiting on you.** Both problems the overnight test found are fixed and proven on
+1. **One thing is waiting on you — item 4, and it takes ten minutes.** Otherwise: Both problems the overnight test found are fixed and proven on
    the real machines:
    - the background job that could delete a live restore's lock now waits its turn — and the check
      that finds the next one like it is a test, not a comment, so it cannot come back quietly;
@@ -37,11 +37,24 @@ nothing.*
    two register lines in the hub (already live). No customer action, no data migration, no
    credential change.
 
-4. **Whether to change the hub password** (R-350). I printed it into my own session log on 20 August.
+4. **The copy that holds the customers' documents and photos can still be deleted by the box that
+   made it** (R-95 — first on the list since July, and this is the first time it has reached this
+   page). I studied it today and did not change anything. **One thing is yours and it takes ten
+   minutes.** Our notes say a safety net is switched on: the storage provider takes a snapshot every
+   night and keeps seven. **I could not find a single one.** I looked from both machines, using the
+   credentials they already have, and checked that my method could see other things and could
+   correctly fail to see a made-up name. Either the snapshots are not being taken, or they are
+   invisible to the machines — and if they are invisible, they are also useless to them: getting one
+   back would be you, in the provider's control panel. **I did not log in to check, because your own
+   notes say that question is yours.** **If you do nothing:** the register keeps saying the net is
+   armed, and nobody knows whether it is. **Please open the Storage Box panel and tell me whether
+   snapshots exist.** The answer changes which fix is worth building.
+
+5. **Whether to change the hub password** (R-350). I printed it into my own session log on 20 August.
    Not in git, not in any saved file — in the log on this machine. **If you do nothing:** it stays as
    it is, at the risk you accept by leaving it. I can change it without ever showing you the new one.
 
-5. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
+6. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
    wrong, or the other way round. **If you do nothing:** the page keeps misleading the next session,
    as it misled one by an hour.