night 2026-10-23 docs: CONTEXT (0.340.0 candidate), REPORT (both review rounds, rc.8 re-proof), the OffsiteStateAwaitingRecoveryKey comment corrected (its hub claim was measured false: felhom.eu R-1230); no behaviour change

CONTEXT.md

@@ -1,5 +1,13 @@
 # CONTEXT.md — Project Memory
 
+> **2026-10-22/23 night — 0.340.0 candidate on `main`, unreleased.** The stray-copy fix (`66a69d4`, `912e592`) and two
+> review rounds (`943c517` C5/C3/C6/C8; `9d9e404` N2–N5, N9; `1babfe9` two races): the capped copy's container has a
+> fixed name + label, is removed by name on any error, leftovers are removed at start before the scheduler/web server
+> (holding the destination's lock), one copy per destination at a time, `RunTier2` refuses during a restore of the app
+> in one step with its record (`beginTier2Run`), every leg asks again; a restore is refused while a copy runs or a stray
+> may run (per-name strays, cleared by a later removal). Proven on 9202 with rc.5 and rc.8; rc.8 runs on the test box
+> (Tester4-16fdef) for the night. Release: 0.340.0 with MinAgent 0.158.1, the operator's yes (STATUS morning list).
+
 > **2026-10-22 night — four fixes on `main`, NOT released (night brief: no release). The next release is 0.340.0, MinAgent 0.158.1.** R-49 (D21 = B): `.felhom.yml` `backup.volumes` class `excluded` (`6a17c95`); R-1187(c): an import over an installed app that is not running is refused (`d5f88a2`, reproduced and proven fixed on 9202); R-1189(d): `nightchain.CatchUp.After` runs the off-site proof + integrity once after a catch-up (`d5f88a2`); R-1214: the second-drive copy runs in a 512 MB memory-capped container for clean `/mnt/` paths with no symlink (`03c0a69`, `ae39467`). 9202 ran rc.1–rc.4 and is back on 0.339.0. rc tags pushed: 0.340.0-rc.1..rc.4 (never offered: not X.Y.Z).
 
 > **2026-10-20 — v0.336.0 is the floor (MinAgent 0.158.1, 08:54 UTC).** R-893 option A (operator D20): a failed off-site restore

REPORT.md

@@ -37,5 +37,23 @@ limit set by ldflags, never pushed) → the timed-out container removed, the par
 | C7 | the image tag, not its ID; no `--pull never` | REAL → fixed; „no memory cgroup → uncapped": NOT-A-FINDING (every Felhom guest is an LXC on a cgroup-v2 Proxmox kernel; the guest's own memory figures come from it) |
 | C8 | README: „out of every backup" | REAL → fixed (the `.fab` export and the whole-guest snapshot still hold it) |
 
-**Images:** `0.340.0-rc.5` (= `66a69d4`), `0.340.0-rc.6` (= `943c517`, on tonight's test box). CI: `66a69d4` 2227,
+## The second review (tonight's own code) and the commits' security review
+
+| # | Finding | Verdict |
+|---|---|---|
+| N2 | one failed `docker rm` refused every restore until a restart | REAL → per-name strays, cleared by a later removal (`9d9e404`) |
+| N3 | the start-up retry removed this process's own copies | REAL → `running` names skipped (`9d9e404`) |
+| N4 | a second copy into the same destination killed the first | REAL → one copy per destination at a time (`9d9e404`) |
+| N5 | `RunTier2` from the „Tier 2 on" save ignored a running restore | REAL, pre-existing → refused for every caller (`9d9e404`) |
+| N9 | the import refusal advised removing an unhealthy app | REAL → „kérd az üzemeltető segítségét" (`9d9e404`) |
+| S1 | the start-up removal could hit a copy starting between list and remove | REAL → the destination's lock (TryLock) (`1babfe9`) |
+| S2 | a restore beginning between the copy's check and its record | REAL → one step under the restore record's lock, every leg asks again (`1babfe9`) |
+
+Each with a test seen failing first; `-race` clean. **Re-proven on 9202 with rc.8** (felhom.eu
+`audits/night-2026-10-23/P1-straycopy/1*`): two runs into the same destination → the second waited, no kill, no failure;
+the restart mid-copy and the restore refusal as before; the redo equal to the source. Also corrected: the comment on
+`OffsiteStateAwaitingRecoveryKey` claimed the hub's delivery check skips a held box — measured false on the test night
+(felhom.eu R-1230, fixed in the hub).
+
+**Images:** `0.340.0-rc.5` (= `66a69d4`), `0.340.0-rc.6` (= `943c517`), `rc.7` (= `9d9e404`, not used), `rc.8` (= `1babfe9`, on 9202 and on the test box for the night). CI: `66a69d4` 2227,
 `912e592` 2228 green; `943c517` and the docs commit: see felhom.eu `REPORT-night-2026-10-23.md`.

controller/internal/backup/offbox.go

@@ -1742,8 +1742,10 @@ const OffsiteStateNeedsCredential = "needs_credential"
 //     so it will not re-stage a credential this box already has;
 //   - `monitor.OffsiteChecker.isStale` returns false unless `Enabled && EscrowState == "escrowed"`,
 //     and this object carries Enabled=false;
-//   - `monitor/offsite_delivery.go` keys on the delivery shape, which is `applied` here (the secret
-//     WAS consumed), and that branch is skipped;
+//   - `monitor/offsite_delivery.go`: this comment once said the branch is skipped (`applied`). MEASURED FALSE on
+//     2026-10-23 (test night, Tester4): the held box carries no offbox target, so the hub read „consumed, never
+//     applied" → a false `offsite_delivery_stuck` mail and a re-issue after one hour. Fixed in the hub (R-1230,
+//     hub 0.167.0 source: this state stands the checker down), pinned by the hub's TestR1230_AHeldBoxIsNotStuck;
 //   - an unknown `state` string is ignored by encoding/json on an older hub.
 //
 // So this needs NO hub change to be safe. It does mean a held box raises no alarm — which is R-243,