hertz -> doyle + todlando. STOP-AND-REFER. KITSUBITO'S DISK IS 100% FULL. A0 IS BLOCKED, AND NOT BY
MY RIG. todlando: do NOT start the listener; you have no go from me and will not have one until this
is resolved.

THE MEASUREMENT:
  df /  ->  938G size, 890G used, 0 AVAIL, 100% USE.   Inodes fine: 2% (61.4M free).
  cargo nextest list exited 101 with "No space left on device (os error 28)" on a dozen fingerprints,
  plus two "rustc-LLVM ERROR: IO failure on output stream: No space left on device".

READ THIS AS UNTESTED, NOT AS A RED. LIST_EXIT=101 says NOTHING about my cells: the link never
completed, so no test binary was produced and no population was ever enumerated. A resource fault is an
untested arm wearing a red's exit code. Everything I reported green earlier still stands on its own
evidence - check --workspace --all-targets exit 0, clippy exit 0, and the injected control at exit 101
naming twohost_bootstrap.rs:406 - because those completed before the wall was hit.

WHAT IS ON THE BOX (du -sh ~/*, largest last):
  39G  rider3
  51G  spt-core-hertz-linux      <- MINE, the lane tree, target/ alone is 51G
  73G  spt-hertz-rigports        <- carries my name; I have NOT verified it is mine or finished
  80G  actions-runner            <- THE CI RUNNER. Not mine, not to be touched by anyone but its owner.
  82G  spt-core-deploy
 102G  spt-core-gate-w2
 159G  projects
 263G  spt-w1
  (.cargo/registry is only 409M - the caches are not the problem; the trees are.)

I AM NOT DELETING ANYTHING ON MY OWN JUDGEMENT, and I want to be explicit about why rather than look
slow: this is a SHARED box that hosts the CI RUNNER, most of those trees belong to other lanes and
other agents, and a target/ I have not classified is exactly what I am on record refusing to remove.
"Reap only your own" is not a preference here - deleting another lane's pool mid-flight would fabricate
reds for someone who would have no idea why.

WHAT I CAN OFFER, in the order I would do it, each needing your word:
  1. MY OWN TREE: ~/spt-core-hertz-linux/target is 51G and is a REAL directory, not a junction or
     symlink (ls -ld confirms). I can reap that subtree and reclaim 51G immediately. Cost: the next
     build is fully cold (the earlier greens are already recorded, so nothing is lost but time).
     This one is unambiguously mine and I will do it the moment you say go.
  2. ~/spt-hertz-rigports (73G) has my name on it but I have NOT established that it is mine or that
     its lane is finished, so I am treating it as unclassified until I check it. I will classify it
     and report, not delete.
  3. Everything else is someone else's to reap. spt-w1 at 263G and projects at 159G are where the real
     space is, and neither is mine to touch.
Even option 1 alone may not be enough: a full workspace test-binary link is tens of GB, and 51G free on
a box that just hit zero is thin. The durable fix is somebody who owns the big trees reclaiming them.

ONE THING WORTH KNOWING BEYOND MY LANE: a root filesystem at exactly 0 bytes free affects EVERY
process on that box, including the CI runner's Linux leg and any other agent building there right now.
If a Linux CI job or another lane goes red in this window, this is the first thing to check - the reds
will look like anything but a disk fault. That is a box-wide incident, not a hertz-lane inconvenience,
and it is the reason I am reporting it before doing anything rather than quietly cleaning my corner.

MY STATE IS OTHERWISE INTACT: branch test/304-twohost-bootstrap off 00c4dad9, rig file blob
5f1d931c5bc0bb6cced15c08b8bf7291ca259b61, toml row activated, working tree clean apart from those two
intended changes. Nothing of mine is running now. No packet has been sent to 192.168.1.81. Waiting on
your ruling for the reap.