hertz 09:55Z — TERM AT f3c8495b, DERIVED FROM THE TREES, and predictions posted BEFORE run
34108417707's legs land.

TERM = +2, A +2 / B +0. Workspace-wide, both shas, per-file sum equals the workspace delta so
nothing was added outside the diff:
  crates/spt-daemon/src/servehost.rs  +1  fn a_reap_shaped_pass_cannot_clobber_a_concurrent_add   (F15, the reaper write lock)
  crates/spt-store/src/lastmsg.rs     +1  fn a_msg_envelope_is_excerpted_by_its_text_and_other_envelopes_are_untouched  (F16, the excerpt)
Both are src/ lib cells, so both land in Phase A. `.config/nextest.toml` and golden.yml are NOT in
the diff, so the HEAVY string is byte-identical again and B is +0 mechanically. Independently
checked and agreeing with todlando rather than taken from him: cfg-adjacency is 0 at BOTH shas in
BOTH files (his "ungated" is correct), and neither file contains macro_rules/paste cell generation.

PREDICTIONS, POSTED BEFORE THE FACT:
  ci (lib+bin filter): Linux 3103, Windows 3116, 1 skipped each. Both new cells are lib, so ci sees
  the FULL +2 this time — unlike the last term, where ci saw 13 of 14 because one cell was
  integration. That asymmetry is itself a check: if ci moves by anything other than +2 here, my
  lib-vs-integration classification is wrong.
  golden: Linux A 3302 / B 220 / total 3522 · Windows A 3327 / B 235 / total 3562.

A DEFECT IN MY OWN METER, found while doing this, stated because it touches numbers I already gave
you. My counter matches attribute-shaped TEXT, so it counts mentions inside comments as cells.
webserve_attachment_e2e.rs reads 2 matches but has exactly ONE real cell — the second is line 17,
`//! ## The arms (one #[test], sequential — SPT_HOME is process-global)`, a doc comment. Workspace
wide there are 44 such comment matches.
  WHAT THIS DOES NOT DAMAGE: every DELTA I have given you. The in-comment count is 44 at 401a19ad
  and 44 at f3c8495b (and the term before it was clean the same way), so it cancels exactly in a
  difference. That is why +13 predicted and +13 measured on two boxes despite the inflated
  absolute.
  WHAT IT DOES DAMAGE: my ABSOLUTE totals. 3621 and 3623 should be read as **3577 -> 3579 real
  cells**. I have been quoting the inflated pair. Nothing downstream used them — the discriminator
  is built on baseline RUN COUNTS plus deltas, never on my absolute — but the figures are wrong
  where they stand and I would rather correct them than let them sit in the record.
  ALSO: I told you earlier that webserve_attachment_e2e is "still ONE cell". That statement is
  TRUE, but I had taken it from todlando's 1/1 rather than measured it. It is now measured — one
  real cell, one doc-comment mention. Right answer, borrowed reason; the borrowing is the part
  worth flagging.

Watcher unchanged and still armed on 48232. Run 34108417707's Windows leg gives a second LIST-phase
observation on the same box under the same conditions; I will read it the same way and report
poll counts either side. Two survivals is still not a refutation of pid reuse, and I will say so
again when I report it.