fix(harness): the no-loss stranding budget sat on the healthy distribution's centre

[wshallwshall]

test_load_runner::test_run_load_end_to_end_no_loss red the required windows-2025 leg on main at 9b03057f. Nothing was lost.

sent=90  acked=44  timeouts=46  nak=0  errors=0
engine_read=52  engine_written=104  sink_received=104  backlog=0
max_drain_seconds: observed 4.7 / threshold 30.0  ✅

104 written, 104 received at the sink, backlog drained in 4.7s of a 30s bound, leg finished in 20:05 — inside every cap. It failed the reconcile.

The budget was the bug

_reconcile excuses unconfirmed sends (in-flight at a connection close, no ACK seen) up to max(unconfirmed_budget, sent // 2), past which it declares a systemic no-ACK fault. report.py documented why that fraction was chosen:

"Observed teardown stranding is ~16%, so half is ~3x the worst seen — wide enough to stop flaking, far from vacuous."

It was sized against a worst-observed of 14/90. windows-2025 has since produced 46/90 (~51%) on a lossless run. The 3× headroom is 0.98×, and the run failed by one message over a budget of 45.

A threshold sitting on the centre of the healthy distribution is a coin flip, not a detector. Same defect as the ubuntu step cap in #104 (a green 775s run against a 780s bound) and as test_coord_lock's arrival-spread assumption — a bound tuned to a single observation, later met by a slower runner.

The two detectors disagreed

tests/test_load_runner.py already recorded the 46/90 observation in a comment, and tuned its systemic-ACK check to acked >= sent // 4 — tolerating 75% stranding. But the reconcile's budget failed at half + 1, so that tuning never applied to the path that actually fires. The comment said "~half is healthy"; the code said "fail above half".

The fix

Three quarters, in all three deliberately-synchronised copies (report, connscale, estate) plus the multishard doc-comment. That's ~1.5× the worst healthy value on record, while a dead ACK path strands ~100% and still blows it — and it makes the two detectors encode the same tolerance.

What I deliberately did NOT change

excused = 0 if over_budget else unconfirmed is a cliff: at the budget everything is excused, at budget+1 nothing is, so the failure detail claimed "lost 38 on intake" for a run that lost nothing. I changed it to clamp, then reverted — test_harness_reconcile pins the all-or-nothing behaviour on purpose ("with the flood masking a real shortfall, nothing is excused: the loss is reported too"), and the cliff is only reachable once the run has already failed. Overriding a deliberate design decision as a side-effect of a different fix is how you get two bugs. Noted in-code for whoever wants to revisit it on its own merits.

The anti-vacuity floor is untouched and still unconditional (read >= sent // 2, enforced separately from the excusal). On the failing run it passed — 52 ≥ 45. The run met the guarantee the budget exists to protect and failed anyway.

Tests

• Cap pin renamed to ..._capped_at_three_quarters_of_the_run, boundary moved to 67/68.
• New regression pin carrying the exact 9b03057f counters (90 sent / 46 stranded / 52 read / 104 delivered) that must reconcile clean, so this specific flake cannot come back.
• 1,371 harness/load tests green, 0 failed. ruff check + ruff format clean. Pre-commit passed.