hertz — CORRECTION FIRST, because the wrong number is in GATE-W2-272-CHECKLIST.md verbatim. Then
the third term.

=== CORRECTION: my growth term was INTEGRATION-ONLY. Phase A and TOTAL were understated by 69. ===

I measured growth as `crates/*/tests/*.rs` and called it the estate. Golden runs `--workspace`, so
lib unit tests (`kind(lib)`) are in Phase A too. Measured across the whole `crates/` tree at all
three shas, cross-checked two ways (per-file split and a whole-tree control, identical totals
3433 / 3514 / 3557): growth baseline -> ff4b405d is +81, not +12. The 12 was the integration slice
of an 81.

WHAT SURVIVES AND WHAT DOES NOT, so you can patch the checklist surgically:
  - Phase B figures STAND unchanged (218 Linux / 233 Windows). The B term was integration-only and
    that was correct — no lib unit test can be HEAVY, since the filter is `kind(test) & binary(...)`.
  - The repartition term 14 STANDS. It was read off the baseline run's own per-test lines.
  - Phase A and TOTAL were WRONG, both boxes, by exactly +69 (the lib half of the 81).
  CORRECTED @ ff4b405d:  Linux A 3245  B 218  total 3463   (was 3176 / 218 / 3394)
                       Windows A 3270  B 233  total 3503   (was 3201 / 233 / 3434)

The mechanism is the one I reported to you twenty minutes ago in someone else's code: a population
defined by where the instrument was pointed. I found the gate's scan root excluded a crate, wrote a
rider about literals not being portable across roots, and then handed you a growth term measured
over one directory tree. Same error, mine, same night.

=== THIRD TERM: ff4b405d -> e3bd53d4, +43, itemised ===
Fetched and verified: origin/build/ws272-w2 tip == e3bd53d4411d1964f70a11f048ad83bc98ac5d5f,
16 ahead / 0 behind ff4b405d — matches todlando's report on both arms.
HEAVY diff, all THREE clauses examined this time (spt, spt-daemon, spt-term), with -E:
package(spt) 44 -> 45, sole addition `webserve_attachment_e2e`; spt-daemon 35 -> 35 unchanged;
spt-term clause present both sides. Exactly one hand-add, as todlando said.

  PHASE B (+2):  spt/tests/webserve_attachment_e2e.rs  0 -> 1   (HEAVY by his hand-add)
                 spt-daemon/tests/twohost_web.rs       4 -> 5   (HEAVY since #198)
  PHASE A (+41): spt-store msgid +14, serving +6, helperline +5; spt-daemon wan +3;
                 spt fetchverb +4, nowsignal +3, attach +2, cli +1, msgverb +1; spt-proto event +1.
Note on your shape message: "twohost_web +4 role cells" is the count from BEFORE #198 (0 -> 4 there,
then 4 -> 5 here). Against ff4b405d it is +1. Flagging so the terms are not double-counted.

=== FULL PREDICTION AT e3bd53d4 ===
Growth baseline -> W2 classified mechanically, every changed file, not hand-assembled: A +117,
B +7, total +124.
  Linux    A 3183 - 14 + 117 = 3286   B 199 + 14 + 7 = 220   total 3506
  Windows  A 3208 - 14 + 117 = 3311   B 214 + 14 + 7 = 235   total 3546
  Skipped: 1 per box, Phase A, assumed unchanged.

UNIT HAZARD, checked rather than waved at: growth is in ATTRIBUTES, the baseline in RUN CELLS, and
at baseline attributes exceeded cells by 51 (Linux) / 11 (Windows) from cfg-gating. So I checked
whether any NEW cell is platform-gated: **zero** of the changed files have a `#[cfg(...)]` within
three lines above a test attribute — the cfg hits in those files sit on helpers, not cells. The
growth term is therefore platform-neutral, the baseline's attribute-vs-cell gap stays constant
rather than widening, and the predicted DELTAS are exact. The absolutes inherit the baseline's
measured cell counts, so they are as good as the deltas.

REMAINING LIMIT, unchanged: an attribute grep cannot see macro- or rstest-generated cells. If any of
todlando's new spt-store cells are generated rather than written, my +41 is a floor for Phase A.