drill 0.243.0: interventions counted (0, O1/O2 apart) and the alarm truth table

Nothing on the walk needed a shell or an operator. The four moments that could be
mistaken for help are listed with the reason each is not one — two of them were my
own errors driving the API, and one was my own damage during the memory test.

The alarm table is now measured from two independent sides: the hub's own log lines
and the inbox. The one-hour operator cooldown is proven to suppress AND to release
(backup_tier_skipped mailed 12:08, suppressed 12:37 and 12:58, mailed again 13:18).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/audits/DRILL-prove-fixes-0243-2026-09-16.md

@@ -104,3 +104,23 @@ listing of ep0 confirms it: `ns/tester-1/ct` is **empty** both before (09:12Z) a
 drill, while the neighbouring `ns/demo-hp/ct` lists group 9201 — the positive control proving the
 listing method shows groups when they exist. **Nothing on ep0 was written, removed or pruned by this
 session.**
+
+## Interventions — counted, with the reason for each verdict
+
+**Pre-declared and counted apart:** **O1** the operator's „Send self-bind link" press (the customer was
+already waiting when the automatic trigger shipped) and **O2** the „Re-issue PBS credentials" press.
+
+**Counted interventions: 0.** Nothing on this walk needed a shell, an operator, or knowledge a household
+does not have. The four moments that could be mistaken for one, and why each is not:
+
+| moment | why it is not an intervention |
+|---|---|
+| the automatic reboot re-entered the installer | a volunteer removes the USB stick and powers the box off and on — the same act. It is a real trap and is recorded as one, not as help from outside |
+| the text-mode installer entry was used | the graphical entry IS keyboard-drivable; the walk switched because *I* cannot see the screen without a screenshot. A volunteer looking at a monitor has no such problem. A deviation of method, declared |
+| the claim form and the drive form each refused once | both refusals were **mine**: I drove the API and guessed field names (`code`/`new_password`/`confirm_password`, and `mount_name` not `label`). A volunteer uses the browser form and never meets them |
+| Paperless had to be repaired mid-drill | **my own damage** — I re-ran `docker compose up -d` by hand during the memory measurement and lost the controller-injected environment. Repaired through the controller's own API. Not a product fault |
+
+**What a volunteer WOULD have hit, as defects rather than interventions:** the console keeps showing the
+pairing banner long after the box is bound and claimed (**R-535**), the drive wizard rejects an accented
+mount name — the first thing a Hungarian types (recorded on the walk), and the backup story in Phase 2
+(**R-537**, **R-538**).

documentation/audits/evidence-drill-0243-2026-09-16/phase3-alarm-truth-table.txt

@@ -46,3 +46,18 @@
 ##  3) Every warning that fired today was true. No warning that should have fired stayed silent, EXCEPT
 ##     the class R-538 names: there is no alarm at all for "a restore finished and the app is now
 ##     inconsistent", so nothing could have fired.
+##
+## MAILBOX SIDE, read directly from the inbox (not from hub logs), 2026-09-16T11:2xZ:
+##   09:59:56Z  to tester1@   "[Felhom] Kosd ossze a Felhom dobozodat"          (self-bind link)
+##   10:01:57Z  to tester1@   "[Felhom] Uj beallito kod - ujratelepult a szervered"
+##   10:04:01Z  to admin@     "[Felhom] tester-1: node_recovered" (info)        <- the by-design info mail
+##   10:08:26Z  to admin@     "[Felhom] tester-1: backup_tier_skipped" (warning)
+##   10:48:47Z  to admin@     "[Felhom] tester-1: app_start_failed" (warning)   <- true; my own damage
+##   11:11:43Z  to admin@     "[Felhom] tester-1: claim_lockout" (warning)      <- F11, true
+##   11:12:06Z  to tester1@   "[Felhom] Beallito kod a jelszavad visszaallitasahoz" (the reset code)
+##   11:18:40Z  to admin@     "[Felhom] tester-1: backup_tier_skipped" (warning)
+##
+## The last line is the COOLDOWN EXPIRY measured end to end: the same event was suppressed at 12:37 and
+## 12:58 CEST ("Operator email suppressed ... cooldown") and mailed again at 13:18 CEST - one hour after
+## the 12:08 mail. So the one-hour operator cooldown both SUPPRESSES and RELEASES correctly, proven from
+## the hub log and from the inbox independently.