[chriscoveries]

This follows the narrower direction requested on #167: one passive diagnostic
for the volume containing CCCC_HOME, independent of Group notice ticks.
ping.diagnostics.disk exposes the cached free/total capacity, sample times,
attempt count and sampling error. No Mail, foreman notice, ledger event or
notification policy is added.

How we built it. The daemon starts one host sampler after acquiring its
exclusive home lock. It samples immediately and every 60 seconds, skips missed
intervals, uses a blocking worker for the filesystem probe, and ends with the
daemon. Status requests only clone the cached result. There is no disk cache
file. An in-flight statvfs call cannot be cancelled: the sampler bounds its
async shutdown wait to 500 ms, but Tokio runtime shutdown can still wait for a
stalled filesystem call. This does not promise bounded daemon shutdown.
The production inbox::notices::NoticeState and
inbox::projection::due paths are unchanged; no legacy reducer is extended.

The diagnostic enters low below 3 GiB available and recovers at or above
4 GiB, with both thresholds exposed in the result. The recovery margin avoids
flapping near the low boundary. These are observations, not write-admission
rules. Failed sampling reports unavailable and keeps the last successful
sample/time and previous hysteresis state; only a later successful sample can
establish recovery. unknown distinguishes the initial unsampled state.

How we tested it. Policy cases replay the original filesystem counts
from three captured Linux statvfs samples; the fixture preserves their
capture timestamps, but the policy tests do not replay those timestamps.
Filesystem paths are redacted; no capacity samples are generated and no
large files are allocated.
The cases cover low entry, the recovery band, healthy recovery, exact boundaries
placed at captured values, and a real failed probe preserving low state. A
small real-filesystem test samples a temporary directory and a missing path,
with no free-space floor. Service cases prove an independent cadence without
Groups or notice ticks, cached reads, home scoping and shutdown cleanup.

Two black-box checks start an isolated actual daemon, read its public IPC,
verify sampling without any Group and verify repeated status polls do not
resample. Their cleanup stops only their own test daemon. The tests-only stock
reference contains these same two checks without any runtime change. Its exact
missing-feature result must be two failures, with compile/setup failures
rejected as negative evidence. The six policy/probe/service cases are tested
on the candidate; they are not claimed as executable against stock APIs.

The check merge 71d8739b899c31a77bd840d52c4c92f6527583c0 combines this
feature with #175's test-profile correction. An independently reconstructed
tree matches the check merge exactly: all nine implementation, test, fixture
and documentation files match feature 33798b21, and only the nextest
configuration differs. The original paired evidence remains bound to its
actual feature and stock source pins.

Six-job check CI is green at that exact merge head: 2,726 workspace tests
pass, with zero failures and 60 skipped. All six new unit cases pass, both
actual-daemon cases pass in the serial suite, and formatting, workspace clippy,
native-session verification and Windows smoke pass. Counterexample review found no blocking issue. Upstream posting remains held
until #175 merges and the PR's own CI is green.

• Source-gate check CI: 39844355071 (all six jobs green).
• Candidate/stock exact pair: 39841131501: six policy/probe/service cases plus both actual-daemon checks pass; stock fails exactly the two missing-diagnostic checks. Compilation or setup failures are rejected as negative evidence.

Tested on: GitHub-hosted ubuntu-26.04 (x86_64 Linux), Rust 1.88.0,
on the fork. Windows smoke passes at check 71d8739b.

[chriscoveries]

CI note: on current main, rust-linux fails the five real-Chrome fixtures added in 1e5651b2 on every pull request. #175 moves them to the nightly job.