An unknown drawn as a zero: the defect v0.226.0's own fix introduced

Writing the REPORT's observation "the no-unit fallback already reports a zero
result, which is honest" exposed that the sentence was FALSE.

A zero UnitRestoreResult is Scenario B's shape. So RestoreFromRecoveryUnit's
fallback to RestoreApp -- which returns only an error, and whose signature is
deliberately out of scope -- would have printed "ez a mentes csak a
beallitasokat tartalmazta, adatot nem" over a restore that may have replayed the
app's entire dataset. That is an unknown drawn as a zero: the exact R-88 failure
direction this whole change exists to remove, re-introduced by the change.

UnitRestoreResult now carries CountsUnknown, the fallback sets it, and there is a
fourth sentence claiming only what is known -- the restore ran, the app is back,
and we cannot say what came back. RestoreApp's signature is untouched.

Pinned by TestUnitRestoreOutcome_NoUnitFallbackSaysUnknownNotEmpty. The A5 seam
test was corrected too: its fixture has no recovery unit, so it exercises exactly
this path and had been asserting the wrong sentence -- it now asserts the
unknown, which is what pins the fallback to it.

IT WAS THE observations GATE REFUSING THE PUSH THAT FORCED THE RE-READ. A gate
written to stop findings dying in an overwritten REPORT.md caught a live defect
instead. Also files R-397 (NotifyIntegrityOK/Failed are dead code AND the
monitoring page advertises a weekly integrity check that does not exist) and
R-398 (resticStep is not a seam, which is why R-358's ordering needed an AST
test) rather than leaving them in a file that is overwritten every session.

REPORT.md is the full run record: baselines re-confirmed, per-test results, the
five red-proofs with their observed output, the live validation with verbatim
Hungarian messages, what was NOT validated and why, teardown across three
layers, and the register 165 -> 167 -> 161.

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

CHANGELOG.md

@@ -109,6 +109,24 @@ fixed:** the fixture refused earlier, at the placement stat pre-pass, so `stops
 the pre-fix code. The scratch is now populated the way a completed download leaves it, and the
 assertions are ordered so a removed gate reports the outage rather than "no error returned".
 
+### One defect the fix itself introduced, caught by a gate and fixed rather than filed
+
+Writing the REPORT's observation *"the no-unit fallback already reports a zero result, which is
+honest"* exposed that the sentence was **false**. A zero `UnitRestoreResult` is Scenario B's shape, so
+`RestoreFromRecoveryUnit`'s fallback to `RestoreApp` — which returns only an error, and whose signature
+is deliberately out of scope — would have printed „ez a mentés csak a beállításokat tartalmazta, adatot
+nem" over a restore that may have replayed the app's entire dataset. **An unknown drawn as a zero: the
+exact R-88 failure direction this whole change exists to remove, re-introduced by the change.**
+
+`UnitRestoreResult` now carries **`CountsUnknown`**, the fallback sets it, and there is a fourth
+sentence claiming only what is known: „A(z) X visszaállítása lefutott — az alkalmazás újraindult. Ehhez
+a mentéshez nem tartozik mentési egység, ezért nem tudjuk megmondani, mi állt vissza belőle." Pinned by
+`TestUnitRestoreOutcome_NoUnitFallbackSaysUnknownNotEmpty`; the A5 seam test was corrected too, because
+its fixture has no unit and so exercises exactly this path while asserting the wrong sentence.
+
+**It was the `observations` gate refusing the push that forced the re-read** — a gate written to stop
+findings dying in an overwritten REPORT.md caught a live defect instead.
+
 **Green gate:** `go build ./... && go vet ./... && go test ./...` — 28 packages, rc 0.
 
 ## v0.225.0 — the hub could not tell an empty off-site store from an unmeasured one (2026-08-30, R-331)