REPORT + CONTEXT: v0.348.0 the global floor; clear_hold proven on the release build

CONTEXT.md

@@ -1,5 +1,13 @@
 # CONTEXT.md — Project Memory
 
+> **2026-10-29 (afternoon, attended) — v0.348.0 RELEASED, the global floor since 14:48 CET (MinAgent 0.158.1).** Image
+> `sha256:672fc1c1…` from `2a0a17a` (CI 2515). D64 = B (`09` §3 decision 283): `clear_hold` is the fifth verb of the closed
+> operator-action list; any hold reason; the running controller clears memory and `settings.json` together through
+> `<data>/ctl/hold.sock` (0600, peer uid checked), and `--clear-restore-hold` goes through it when a controller runs
+> (R-1343). R-1340 (both producers name the real cause), R-1341 (OOM line once per kill), R-1342 (no delete during the
+> stable-start watch). Proven live on Tester 1 on the release build: a crash-loop hold cleared from the hub stayed
+> cleared after the next settings save. Open: R-1350 (an `app_start_failed` 30 s after a clear), R-1347, R-1348.
+
 > **2026-10-29 (attended release run) — v0.347.0 RELEASED, the global floor (MinAgent 0.158.1).** Image `sha256:c79b06e6…`
 > from `fd75c7c` (CI 2491); rc.1 = `e3fce09` on scratch 9202. Carries the night's R-1256 (all four edges, H4 + H5's
 > failed stop proven live on Tester 1 with a `-tags faultinject` test build — D63), R-1254 controller half, R-528, the