final walk: the soak DID catch a scheduled cycle; both directions recorded

Window 2 (01:56-02:36Z) caught the off-site nightly at 02:15:03Z — snaps 1->2,
last_run advanced with no prompting. Window 1 had already caught the local legs
(db-dump 00:30:25Z, tier + fill-watch 01:30:19Z). My 04:15 prediction was wrong in
the other direction; recorded rather than quietly fixed.

What should have fired and did not: NOTHING. Six registered jobs were never seen
in the log and none is a finding — four are quiet by construction
(scheduler.go:267, quiet := job.Interval <= 30s) and two run every 6h, outside a
4h window. Checked the source rather than filing four phantom defects.

What fired and should not have: nothing. No alert, notification, email or digest.
The only WARN lines in five hours were three of mine.

Observation kept: offbox-backup ticked twice 62s apart and produced ONE new
snapshot — the second silently dropped by the single-flight, which is correct for
the nightly path and is the same mechanism that produced R-234 on the manual path.

documentation/tests/finalwalk-r201-2026-08-07/journal.md

@@ -147,3 +147,40 @@ unchanged throughout (`last_run` fixed at `22:38:54Z`, `snaps=1`, `12.0 MB`).
 > screen before 07:00 is the primary deliverable (§11.1), and waiting for it would have put the
 > destruction at ~06:35 CEST with no margin. **Recorded as not run, with the reason** — the off-site
 > tier was exercised four times manually tonight instead, including a full listing by name.
+
+**Window 2: 01:56:28Z → 02:36:45Z — and the nightly DID fire, unprompted.**
+
+```
+00:30:25Z  db-dump
+01:30:19Z  tier + fill-watch          ← the local tier legs
+02:00:35Z  metrics-prune
+02:15:03Z  offbox-backup              ← the off-site nightly
+02:16:05Z  offbox-backup
+           offbox: snaps 1 → 2, last_run 22:38:54Z → 02:15:24Z
+```
+
+So the soak covered a genuine scheduled cycle after all: the local legs in window 1 and the off-site
+nightly in window 2. **My 04:15 prediction was wrong in the other direction — it fires at ~02:15
+controller time.** Both the prediction and the correction are recorded rather than quietly fixed.
+
+**BOTH DIRECTIONS, as §6.1 demands:**
+
+*What fired and should have:* every periodic job at its cadence; the DB-dump, tier and fill-watch
+legs; metrics-prune; the off-site nightly, which added the second snapshot with no prompting.
+
+*What should have fired and did not:* **nothing.** Six registered jobs were never seen in the log —
+`health-probes`, `status-refresh`, `ring-spill`, `deadapp-check`, `disk-health-check`,
+`selfupdate-check` — and **none of them is a finding.** The first four are **quiet by construction**
+(`scheduler.go:267` — `quiet := job.Interval <= 30*time.Second`, so a ≤30 s job never emits
+`Running job:`), and the last two run every 6 h, outside a ~4 h window. *An absent log line is not
+evidence* cuts this way too: I checked the source rather than filing four phantom defects.
+
+*What fired and should not have:* nothing. No alert, notification, email or digest. The only `WARN`
+lines in five hours were **three of mine** — a failed login attempt, a CSRF token I mangled, and T1's
+deliberate `opengist` skip, which logged correctly.
+
+**One observation worth keeping:** `offbox-backup` ticked **twice, 62 s apart**, and the snapshot count
+went 1 → 2, not 1 → 3. The second run was silently dropped by the single-flight — which for the
+NIGHTLY path is correct and deliberate (nobody asked; the next run retries). It is the same mechanism
+that, on the MANUAL path, produced R-234; v0.205.0 changes only the manual half and leaves this one
+silent, and this soak is live corroboration that the nightly half genuinely needs to stay quiet.