R-101 + F-DIAG: the restore dialog names the last SUCCESSFUL copy (v0.182.0)

Tier2LastRun is the attempt clock and was rendered as 'Legutóbbi másolat' in the restore
confirm dialog. New LastSuccess + SuccessTracked anchor; tier2Update makes the three
rebuild sites safe by construction. F-DIAG: six distinct causes, target-aware redaction.

CHANGELOG.md

@@ -1,5 +1,52 @@
 ## Changelog
 
+### v0.182.0 — R-101 + F-DIAG: the customer must not be told a failed backup is a copy (2026-07-28)
+
+**R-101.** `Tier2LastRun` is the ATTEMPT clock — `recordTier2Failure` writes it too — and it was
+rendered as „Legutóbbi másolat" in the **restore confirm dialog**. That is misinformation at a decision
+point, not an alarm bug: the restore it guards fills in MISSING files without touching existing ones,
+so a customer whose Tier-2 had been failing was told a copy existed from last night, restored, and
+silently received **older** files while believing they were recent.
+
+`CrossDriveBackup` gains `LastSuccess` (same rule and shape as the offsite anchor) plus
+`SuccessTracked`, which distinguishes "this row predates the anchor" from "this row has one and it is
+empty". Without that marker the two are indistinguishable and **all 7 Tier-2 rows on the fleet** would
+have flipped to „Még nincs sikeres másolat" on deploy. Legacy rows are migrated truthfully on first
+touch: a row whose last known state was `ok` adopts that time; a row whose last state was `error` seeds
+nothing, because the old data evidences no success.
+
+Shipped strings: „Legutóbbi sikeres másolat: {dátum}" · „…Figyelem: a legutóbbi mentési kísérlet nem
+sikerült, ezért a visszaállított fájlok ennél régebbiek lehetnek." · „Utolsó sikeres: {relatív}" ·
+„Még nincs sikeres másolat" with the restore replaced by „Még nincs sikeres másolat, amiből vissza
+lehetne állítani." The dialog also stops printing a raw UTC RFC3339 stamp — new `fmtTimeStr` renders
+Budapest-local `2026-07-25 03:30`.
+
+**Part 2 — the copy-site hazard, and it was in the path.** The three `record*` helpers each built a
+WHOLE `CrossDriveBackup` literal with a helper re-applying exactly two fields; everything else was
+zeroed on every status write. Adding `LastSuccess` to that shape would have had `recordTier2Failure`
+**clear** it — the mirror image of the defect, firing on the first failure. Replaced with
+`tier2Update`, which copies the existing row and overlays the outcome: **safe by construction**, a new
+field carries over unless deliberately overwritten. Sweep: `SetTier2Preference` mutates in place
+(safe); `SetCrossDriveConfig(name, nil)` is a deliberate delete.
+
+**F-DIAG.** The offsite failure notification was `"…: " + err.Error()` — one string for every cause AND
+a raw passthrough. `ClassifyOffsiteFailure` now returns quota / orphaned / no_repo / no_units /
+transport / **unknown** (unclassifiable says so rather than being folded into a neighbour), each with
+its own Hungarian message.
+
+**The secrets half caught a bug in my own first attempt.** The initial sanitiser regex-matched
+`sftp:…` and `user@host` and looked complete; its own test caught it leaking on
+`ssh: connect to host <host> port 23: Connection refused`, a bare hostname in neither shape. It now
+redacts the target's **actual** host/user/repo-path literally, with the regex kept only as a backstop —
+guessing at what a secret looks like fails exactly where it matters.
+
+Red-proofs, all observed failing: dialog back on the attempt clock → `the dialog does not name the last
+SUCCESSFUL copy`; gate the restore on `LastRun` → `a tier that has NEVER succeeded still offers a
+restore`; make the caution unconditional → `a HEALTHY tier shows the failed-attempt caution`; clear the
+anchor on failure → `a FAILED run wiped the success anchor`; raw sanitiser → `the repo reference reached
+the message ("sftp:" leaked)`.
+
+
 ### v0.181.0 — R-100: record the last SUCCESS, not just the last attempt (2026-07-28)
 
 The producer half of R-100. `OffboxTarget` gains **`LastSuccess`** (RFC3339), carried to the hub on the