R-353/R-357/R-358/R-360: the restore tells the truth (v0.226.0)

Four defects on the restore surface, all proven on demo-hp during the 2026-08-21
backup-truth drill, all still in shipped code. They share one acceptance idea: a
restore surface must state what it actually did, and must refuse what it cannot
do.

VERSION NOTE. The task specifying this targeted v0.224.0 against baseline
f8c9390. Both were consumed earlier the same day by R-330 (0.224.0) and R-331
(0.225.0). Drift re-confirmed against live Gitea before the first edit, operator
authorised proceeding, every symbol the spec named re-verified present at the
real baseline e5eee50.

R-353 -- a restore that gave back nothing still said it worked.
RestoreFromRecoveryUnit returned only error, so the surface printed
"<app> visszaallitva (<snapshot>)." -- equally true of a run that returned an
entire dataset and one that returned nothing. The count already existed and was
discarded one line deep: restoreDockerVolumesFrom always returned it, the
wrapper threw it away. Now (UnitRestoreResult, error), carrying replayed counts
AND what the manifest LISTED, because zero-replayed has two causes that are
opposite news. Three cases, three sentences, and EVERY one is a claim about the
BACKUP, never about the app -- this path has no SafetyDump discriminator, and
07-backup-architecture 6.3 records that an absent dump says nothing about the
app (R-361 destroyed canonical .sql files for four months).

R-357 -- the destructive restore had no free-space gate. offbox_reconstitute.go
contained ZERO references to offboxFree; all three existing gates guard
non-destructive paths. The gate now sits before mapOffsiteRestorePaths,
writeSafetyDump and StopStack, so a refusal costs nothing. Position IS the fix,
which is why the test asserts StopStack was never called. No headroom multiplier
(matches PlaceOffsiteRestore; the x1.1 elsewhere predicts a download). Fail
closed on either probe <= 0 -- otherwise `free < need` with need==0 is FALSE and
an unmeasurable scratch sails through: a gate present and inert.

R-358 -- a failed download was offered as a good one. The gate answered "the
directory exists and is non-empty", which is exactly what a part-way restic run
leaves. Now a completion marker written 0600 atomically AFTER restic returns
nil, with any stale one cleared BEFORE it starts; both orders pinned by an AST
test because resticStep is not a seam. Both handlers refuse server-side: the
wizard flags control a button, and a hidden button is not a guard.

SCENARIO F ANSWERED, and worse than the question assumed: a unit-only scratch IS
reachable through the real flow, by the most ordinary route. "Ellenorzo
visszaallitas" (mode=unit, advertised non-destructive) writes the SAME directory
-- offboxRestoreScratchDir ignores `full` and --include limits what restic
extracts, never where -- so a customer who ran the SAFE restore was then offered
the destructive one over a unit-only copy. Filed R-396; the marker closes it.

R-360 -- the delete refused only while a BACKUP ran. IsRunning() is FALSE for the
whole of a verification restore; the five sibling handlers all use
restoreOpBlocked(). Its doc comment claimed it already did this, which is why
nobody looked -- corrected in place.

Red-proofs, each printing the pre-fix behaviour, in CHANGELOG and REPORT. The
first R-357 red-proof exposed a hollow test OF MY OWN and it is recorded rather
than quietly fixed: the fixture refused earlier at the placement stat pre-pass,
so `stops == 0` passed against the pre-fix code. Fixture corrected, assertions
reordered so a removed gate reports the outage rather than "no error returned".

Green gate clean: 28 packages, rc 0. All 12 controller gates OK.

CONTEXT.md

@@ -7,7 +7,32 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-08-23 (v0.223.0 — R-329: the alarm reached nobody; R-386: ask the field that knows)
+Last updated: 2026-08-30 (v0.226.0 — R-353/R-357/R-358/R-360: the restore tells the truth)
+
+> **2026-08-30 — v0.226.0. TWO RULINGS THIS SESSION MAKES, recorded so neither is re-litigated.**
+>
+> **1. A local restore's outcome is a claim about THE BACKUP, never about the app.** This is R-355
+> extended from the off-site path to the Tier-1 path. On the off-site path `SafetyDump` is an honest
+> discriminator for "does this app have a database" — a path is returned only when a live database was
+> found AND dumped. **The local unit-restore path has no such discriminator at all**, so no claim about
+> the app is available to it. „ennek az alkalmazásnak nincs adata" and every variant is forbidden in
+> `unitRestoreOutcomeMsg`. It is not merely unproven but unprovable from a manifest:
+> 07-backup-architecture §6.3 records that an absent dump has causes that say nothing about the app —
+> R-361 destroyed apps' canonical `.sql` files for four months, and a restore in that window would have
+> "proven" a database-bearing app had none.
+>
+> **2. The destructive reconstitute uses NO headroom margin**, matching `PlaceOffsiteRestore` and
+> deliberately NOT `OffboxRestorePrepareFull`'s ×1.1. The ×1.1 exists because that gate is *predicting*
+> the size of a download it has not made. The reconstitute copies a tree that already exists on disk,
+> so its size is measured, not estimated, and a margin over a measured value is a refusal with no fault
+> behind it. Stated in a comment at the gate as well, because the two neighbouring gates disagreeing
+> looks like an oversight to a reader who does not know which is predicting.
+>
+> Also this session: three earlier-day releases stacked in front of this one — v0.224.0 (R-330, the
+> nightly backup alarming about the apps it was holding down) and v0.225.0 (R-331, `stats_known` on the
+> wire). **The task specifying v0.226.0's work was written against v0.223.0 and targeted v0.224.0**; the
+> drift was re-confirmed against live Gitea before the first edit rather than assumed.
+
 
 > **2026-08-23 — v0.223.0 (R-329 + R-386), and a defect that only became visible once another was fixed.**
 >