ci: enforce the coverage floor instead of only measuring it

[MichaelTaylor3d]

Closes DIG-Network/dig_ecosystem#3033.

What changed

ci.yml carried --fail-under-lines 80as a comment. The coverage job measured, printed, and
ignored the number, so a PR below the floor still went green. CLAUDE.md §2.3 requires every repo
CI-gated at ≥80% with a build below the floor FAILING. The flag is now on the actual command, and the
job-summary heading no longer says measure-only.

Worse than no gate: the machinery being present is exactly what made its absence invisible. A
reviewer seeing a green coverage check concludes the floor held.

The real number (measured BEFORE enabling anything)

cargo llvm-cov nextest --workspace --locked --retries 2 --summary-only, full workspace, 2015 tests,
exit 0:

metric	total	missed	%
lines (what the gate reads)	63,882	7,875	87.67%
functions	7,672	1,381	82.00%
regions	103,301	13,987	86.46%

The repo is above the contract floor, so the gate is set at 80 — the contract's value, not a
number tuned to whatever passes today. Headroom is 7.67 points of lines.

Note on reading that table: llvm-cov's summary columns run Regions, then Functions, then Lines, and
the leftmost pair is the largest, which invites reading the region number as the line number. The
gated metric here is the third block, 87.67%.

Exclusions

None. No --ignore-filename-regex was added. Nothing had to be excluded to reach green, so
nothing was; an exclusion list is only honest when each entry carries a reason, and here there are no
reasons to state. (Sibling repos do exclude bin targets — dig-app and dig-installer both ignore
main.rs/src/bin — but dig-node clears the floor with those files counted, so it stays stricter.)

Blast radius

CI configuration plus a patch version bump; no library or binary code is touched. The changed-symbol
set is empty — the diff is .github/workflows/ci.yml, Cargo.toml, Cargo.lock (the lock entry
for dig-node-service follows the workspace version, so --locked still resolves). The real blast
radius is every future PR to this repo, which is the point: from here a PR that drops line coverage
below 80% fails a required check.

No overlap with the sibling lane on crates/dig-wallet/src/sage/peer_reads.rs + the DB layer
(dig_ecosystem#3035) — this branch touches none of those files.

Version

0.121.0 → 0.121.1 (patch — CI/chore, no behaviour change).

How verified

The full instrumented workspace run above is the same invocation CI runs, now with the flag appended;
it completed exit 0 at 87.67% lines. --fail-under-lines is llvm-cov's own exit-code mechanism, so
the enforcing form differs from the measured form only in that a sub-floor total exits non-zero.

[MichaelTaylor3d]

The gate is load-bearing — proven from both sides on identical coverage data.

Same profile, two floors, exit codes captured before any pipe (piping into tail reports the pipe's status, not the tool's — that is the exact bug the set -euo pipefail comment above this step exists to prevent):

cargo llvm-cov report --summary-only --fail-under-lines 99 -> EXIT 1
cargo llvm-cov report --summary-only --fail-under-lines 80 -> EXIT 0
TOTAL ... 63882 lines, 7875 missed, 87.67%

So the flag genuinely fails below its floor and genuinely passes at it; a floor tested only from the passing side would confirm nothing but itself.

CI is green with the flag live. Run 31964180875, job Test + coverage, 23m34s, and the log shows the enforcing form actually executed:

cargo llvm-cov nextest --workspace --locked --retries 2 --fail-under-lines 80 --summary-only | tee coverage-summary.txt

All other required checks pass (Clippy, Rustfmt, CodeQL/Analyze x3, version increment, commitlint, all four package builds).