v0.191.2 — a quiet fill check now says so (R-167)

Earned during v0.191.1's own live validation. After the customer had been
warned, a restart produced ZERO fillwatch lines — equally consistent with
'ran and chose silence' and 'never ran'. Proving the checker was alive
needed a deliberate crossing into the critical band.

For an edge-triggered check the quiet run IS the healthy steady state, so
that ambiguity is permanent rather than rare. Check now logs a per-RUN
summary on every run, counting unreadable separately from healthy so a
drive that has quietly gone unreadable cannot read as 'all fine'.

CHANGELOG.md

@@ -1,5 +1,22 @@
 ## Changelog
 
+### v0.191.2 — a quiet fill check now says so (2026-08-02, R-167) — MinAgent: none
+
+**Earned during v0.191.1's own live validation, which is the strongest evidence it was needed.** After
+the customer had been warned about `/mnt/sys_drive`, the controller was restarted and produced **zero
+`fillwatch` log lines** — and that was read, correctly, as unusable: an absent line is equally
+consistent with *"the check ran and chose silence"* and *"the check never ran"*. Proving the checker
+was alive required deliberately crossing into the critical band.
+
+That ambiguity is **permanent, not rare, for this check specifically**: it is edge-triggered, so the
+HEALTHY STEADY STATE IS A QUIET RUN. Standing rule 3 aimed at the one place it costs most.
+
+`Check` now logs a per-RUN summary — `checked N filesystem(s), M unreadable/skipped, K
+notification(s); bands: …` — on every run, healthy or not. **Unreadable is counted separately from
+healthy**, so a drive that has quietly gone unreadable for weeks cannot read as "all fine". Two tests
+pin it, including that a second, equally quiet run logs again (the observable is per run, not per
+change).
+
 ### v0.191.1 — the fill check also runs at startup (2026-08-02, R-167) — MinAgent: none
 
 **Found while live-validating v0.191.0 on guest 9201: the fill check was reachable only on its daily