Night 2026-10-28 docs: REPORT (H5 + H8 live on 9202, teardown), README (restore edges, host OOM count — unreleased), CONTEXT, CHANGELOG live line

controller/README.md

@@ -1034,6 +1034,13 @@ Each app can define rich metadata in `.felhom.yml`:
     `healthy`; the copy then goes after a further 3 min of the same (10 s samples, watched up to 30 min; a new restore
     of the app ends the watch). A restore whose app does not start reads „…még nem indult el…", keeps the copy and
     alarms the operator once (D49 = A: nothing is poured back by itself). `restore_verdict.go`. `offbox_restore_undo.go`.
+  - **Restore edges (unreleased, R-1256, night 2026-10-28).** A put-back whose stop fails pours nothing, keeps the copy
+    and holds the app; a failed definition write-back keeps the copy; a volume whose `docker volume rm -f` fails is a
+    failed volume (never unpacked on top of the old content). An off-site restore whose definition write fails writes
+    the LIVE definition back before the start, or holds the app. Every restore begins in one step with the check for a
+    restore, the backup run and a second-drive copy (`TryBeginRestoreOp`, also both kept loads). A copy that nothing
+    needs (no hold of any kind, not named by the app-stop marker, no restore running) goes after 14 days, checked every
+    6 h (`restore_copy_sweep.go`; decided by CC unattended — operator may reverse).
   - **A restore cut by a power loss, on a drive that comes back late (unreleased, R-1251).** The copy of the live
     data lives on the app's drive. When it cannot be reached at start because the drive is not bound yet, the app is
     HELD (`putback_pending`; „…A visszaállítás előtti adatai egy meghajtón vannak, amely most nem érhető el…") and no
@@ -1488,6 +1495,10 @@ The nightly backup has two phases that run sequentially. All paths are **per-dri
 
 > **OOM visibility (v0.243.0, R-514).** The 30 s dead-app check also reads `State.OOMKilled` for running app containers (`Manager.ScanOOMKilled`); the dashboard shows „Memória elfogyott" and the hub gets `app_oom` once per container run. The controller does not restart the app.
 > **OOM storm (v0.265.0, R-636).** For a flagged container the scan also reads the kernel's own kill counter (`memory.events` `oom_kill`, plus `memory.max` / `memory.peak`) with one `docker exec … cat` — `OOMKilled` is sticky, so it cannot count. When the SAME container run's counter rises by **20 or more within 30 minutes**, the notifier sends **`app_oom_storm`** (severity `error`, operator-only, details `{app, container, kills, window_min, mem_limit, peak}`) — ONCE per container run. `app_oom` itself is unchanged. An unreadable counter (an image without `cat`) never escalates.
+> **Host OOM count (unreleased, R-528, night 2026-10-28).** Docker inside an LXC guest misses real OOM kills. The scan
+> also asks the agent for the host's per-container `oom_kill` (`GET /guest/oom-kills`, 5 s cap; a 404 from an older
+> agent → 10 minutes before the next ask); a count above zero raises `app_oom` whatever `OOMKilled` says, with `source`
+> (`docker`, `cgroup` or `docker,cgroup`) in the details. `cmd/controller/hostoom_wiring.go`, `internal/stacks/oom.go`.
 
 > **Multi-tier whole-guest backup (v0.174.0, R-82 Slice B).** The agent can serve SEVERAL whole-guest
 > backup tiers with independent cadences — "local daily + PBS weekly" (agent >= v0.97.0,