R-893: hold the app after ANY failure once the definition or a volume moved; hold persisted before the stop; run_job done says it ran, not what it found (security review)

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

CHANGELOG.md

@@ -34,6 +34,15 @@ nothing breaks).
   the operator is told through the existing `backup_run_failures` event (leg `restore-hold-mixed`, no new hub type).
   No version change and no volume replaced → today's behaviour (`TestR379_ScenarioA` green). Tests `TestR893_*`.
   Known limit: placed files are not undone (the second half, „put back exactly as it was", is its own row).
+  **Security review fixes (same evening):** the same hold now covers EVERY failure after the snapshot's definition is
+  written or a volume replaced — a failed placement (after a definition write), a failed volume replay that replaced
+  at least one volume, a failed DB-only start — not only a failed replay (`TestR893_AVersionChangeThenAFailedDBStartHoldsTheApp`;
+  `TestR354_ScenarioE` updated: a partly replaced volume set now HOLDS instead of starting, the volume named in the
+  operator's notice); the hold is persisted BEFORE the stop, and the app-stop marker is kept when it cannot be
+  (`TestR893_HoldIsPersistedBeforeTheStop`); new household sentence `err.backup.restore_failed_held_mixed` (hu+en)
+  for the non-replay cases; the hold note no longer claims the database is the pre-restore one. Placed files ALONE
+  still do not hold (option C as ruled). **D1:** a `run_job` „done" now says it ran, not what it found (the two
+  off-site checks return nil whatever their verdict).
 
 ## Unreleased (2026-10-08, afternoon) — three dashboard layout fixes: the Apps card header (R-909), the launcher on a phone (R-907), the empty „+5 more warnings" (R-906) — ships with tomorrow's release