Campaign 10: correct R-157 — the failure is INTERMITTENT (3 of 6), not deterministic

The first write-up said R-157 reproduced "at the same cycle in both runs -
deterministic, not a coincidence". Wrong. The cycle numbers matched only because
the runner's RNG is seeded so both runs drew the same permutation. The failure
itself is a coin flip: run 2b's four hard resets went PASS(c2), FAIL(c10),
PASS(c18), FAIL(c26); run 2a went PASS(c2), FAIL(c10). Three failures in six.

The correction matters because it changes what kind of bug this is, and it
strengthens rather than weakens the root cause: intermittency is exactly what a
race against container-state settling predicts, whereas a wrong predicate would
fail every time.

Signature is identical on all three occurrences: rallly Exited 255 with
rallly-postgres healthy, bootrecon reporting "no boot-orphaned apps" about 5s
after controller start, and the container count still churning after the sweep
(third occurrence 01:05: refresh 8, bootrecon 01:05:13, then 8 -> 7 -> 8).

documentation/audits/CAMPAIGN-10-two-storage-soak-2026-07-31.md

@@ -292,8 +292,10 @@ when the run started.
 
 ### R-157 — bootrecon's start-ONCE sweep acts on an unsettled snapshot; the boot orphan survives
 
-**New. Register grepped: R-52 is the feature, nothing covers its timing.** Reproduced twice, in two
-independent runs, at the same cycle (seeded permutation). Full evidence:
+**New. Register grepped: R-52 is the feature, nothing covers its timing.** **INTERMITTENT — 3 of 6
+hard resets (~50%)** across two runs, with an identical signature each time. (An earlier draft called
+this deterministic because the failing cycle numbers matched; they matched only because the runner's
+RNG is seeded. Intermittency is what a race predicts and a wrong predicate does not.) Full evidence:
 `../tests/campaign10-evidence-2026-07-31/r157-bootrecon-start-once-race.md`.
 
 A `qm reset` mid-backup brought everything back **except the app half of the DB-backed stack**: