S44 CI: score D-6 coverage from merged DA: lines, not the double-counted LF:/LH: summary

[hyperxpro]

Problem

The D-6 coverage gate is a coin flip — 3 RED / 3 green on effectively identical production source:

run	h2_proxy.rs	gate
28334977156 (art 7938582116)	79.60%	RED
28334977156 (art 7938395373)	79.70%	RED
28336426614	80.18%	green
30745595161	79.65%	RED
30749813681	80.23%	green
30751410142	80.13%	green

main is green today by luck. This also corrects two earlier records: the handoff called it "~1 run in 4" red, S43 called it "three of four samples fail" — with six samples it is ~50/50.

Cause

Re-verified independently from the RED artifact rather than inherited from the S43 write-up. lb-l7 is compiled twice and llvm-cov merges both instantiations into one SF: record whose LF:/LH: summary double-counts shared source lines:

h2_proxy.rs  declared LF/LH : 1887/1503  -> 79.65%   <- what the gate read
             distinct DA:   : 1780, hit 1441 -> 80.96%
             FN: entries    : 596  (421 CsdExPruU9iqX_5lb_l7 / 175 CsbnMibX7jh97_5lb_l7)

The second instantiation is the lib-unit-test build, which cannot reach the request hot path at all — hyper::body::Incoming has no public constructor — so its unhit lines were scored as genuine misses. This is systemic: 29 hot-path modules are dual-instantiated; h2_proxy was just the only one sitting on the boundary.

Fix

Score merged DA: records — each source line counted once, hit if any instantiation ran it. Threshold stays 80.0. Patterns unchanged. The single named loader.rs carve-out unchanged. Nothing waived or exempted.

This is a correction, not a relaxation — and the re-baseline proves it

Of 31 hot-path modules: 9 up, 12 DOWN, 10 unchanged, 0 below 80%.

A relaxation is a one-way ratchet — it cannot make random.rs (86.21→85.71), conn_gate.rs (91.14→90.91) or conn_actor.rs (85.01→84.79) stricter, which this does, because double-counted hit lines leave the numerator too. Full 31-row table in audit/ci/s44-coverage-metric-rebaseline.md.

Two latent defects fixed in passing

• the old parser did files[cur] = … per record, so multiple SF: records for one file were last-record-wins;
• writing the merge as if cnt > d.get(ln, 0) is a trap — 0 > 0 is False, so a line hit by no instantiation never enters the dict, silently leaves the denominator, and every file scores 100%. Caught only because the expected value (80.96%) was known in advance; a pass/fail-only check would have shipped it green.

Verification

Every value cross-checked against an independently written scorer, not the gate's own output.

sample	old → new	gate
red 30745595161	79.65% → 80.96%	exit 0
green 30749813681	80.23% → 81.57%	exit 0
green 30751410142	80.13% → 81.52%	exit 0

Load-bearing negative controls — the gate must still fail when coverage genuinely drops:

control	expect	result
zero 576 of 1441 hit lines	RED	48.54%, exit 1 ✅
1424/1780 (exactly 80.00%)	pass	exit 0 ✅
1423/1780 (79.94%)	RED	exit 1 ✅
all paths renamed	fail closed	exit 1 ✅
empty LCOV	fail closed	exit 1 ✅
carve-outs	exactly 1	✅

Single-line discrimination at the floor — the gate is non-vacuous.

What this does NOT fix

The ~0.6 pp run-to-run jitter is untouched; only the level moves. h2_proxy now sits ~1.0–1.6 pp above the floor instead of straddling it — a real margin, not a comfortable one. If it drifts down again the honest fix is real coverage (S43 option (c)), not another metric change.

Follow-on

With this landed, Coverage (per-module hot-path >= 80%) becomes safe to add to required status checks. Before it, requiring that check would have blocked ~half of all PRs on a measurement artifact. Owner copy-paste pack for branch protection + the SOAK_* values: audit/release/owner-actions.md.