fix(coverage): make required coverage evidence execute owned Rust line and branch measurement

[seonghobae]

Finding

Fresh consumer evidence from ContextualWisdomLab/fast-mlsirm#1816@b5fec1d33c02e8ea969405e59747f0505e690d20 shows that the centrally required coverage-evidence context can be GREEN without executing repository coverage at all.

Check coverage-evidence job 103274274768 contains only:

echo "This required-workflow job preserves the stable branch-protection context without executing pull-request content."

and then succeeds. The companion coverage-source-tree context likewise does not establish owned production line/branch percentages. The repository's own .github/workflows/ci.yml executes Rust/Python tests, package/fuzz/GPU evidence, but has no source line/branch measurement job. Therefore a green required context is presently insufficient evidence for the organization policy requiring owned production Test / Edge Case Coverage at 100%.

This is a central evidence-contract defect, not permission to weaken coverage policy or to fabricate a percentage in leaf PRs. It is related to #591's trusted offline Rust coverage toolchain work but distinct: even a repaired toolchain does not help when the required consumer context does not invoke the measurement.

Required repair

Make the central required workflow produce immutable exact-head coverage evidence for repositories that own Rust production code, using the trusted offline/sandboxed execution path rather than executing mutable PR workflow code with elevated credentials.

At minimum the receipt must distinguish and report:

• exact repository/head SHA and owned-source classifier;
• production statement/line denominator and covered count;
• unique source branch-arm denominator and covered count (not LLVM raw duplicate regions);
• exact missing files/lines/branch arms when below 100%;
• rustdoc/docstring denominator where applicable or a separate authoritative receipt;
• artifact IDs/digests for raw coverage evidence;
• fail-closed behavior when measurement cannot execute.

Do not satisfy this by a no-op context, continue-on-error, skipped measurement, source rewriting, denominator exclusions invented by the workflow, or treating test success as coverage success.

Acceptance

• A fresh repository_dispatch/required-workflow run against fast-mlsirm#1816 actually instruments and executes the exact head and either proves 100% owned line+branch coverage or reports the exact misses.
• The required check context cannot be GREEN when the measurement did not execute.
• The receipt is reusable by TEPP and other Rust owners without leaf-specific provider credentials or mutable central-source pinning.
• fix(review): update offline Rust coverage toolchain #591's coverage toolchain constraints remain preserved and integrated rather than bypassed.

Consumer: ContextualWisdomLab/fast-mlsirm#1816
Canonical numerical owner issue: ContextualWisdomLab/fast-mlsirm#1814
Downstream consumer RED: ContextualWisdomLab/TEPP#310.

[seonghobae]

Fresh current-head consumer canary from ContextualWisdomLab/fast-mlsirm#1816@432765ccf633c9802e0f796ceeb4d6d572059acf strengthens the Rust-coverage owner RED.

Required OpenCode run/job 34606293205 / 103285500264 completed the source review without a source-backed product finding, then failed coverage enforcement. Its own changed-line report shows every changed Python line covered:

• python/fast_mlsirm/__init__.py: 5/5
• python/fast_mlsirm/estimators/marginal.py: 20/20
• python/fast_mlsirm/estimators/marginal_contract.py: 2/2
• python/fast_mlsirm/capabilities.py: 3/3
• python/fast_mlsirm/config.py: 5/5

The sandboxed Python suite itself executed successfully (920 passed), but aggregate Python production coverage was only 42%, which is inherited repository-wide debt rather than evidence for the new Rust numerical implementation. The actual material product delta in #1816 is the Rust correctly-rounded finite-binary64 mean/superaccumulator. Current central coverage-evidence / coverage-source-tree success contexts still do not provide an executable exact-head Rust line+branch receipt for that owned delta.

Therefore the leaf cannot honestly claim the requested 100% owned production line/branch coverage from the current green context, and it also must not invent Python line-touch tests or exclusions to compensate. Please retain this exact 432765... canary in #2099 acceptance: central coverage needs to instrument the Rust exact head and either prove 100% line+branch/edge coverage or emit exact misses, while keeping malformed/missing measurement fail-closed. No no-op context, source rewriting, denominator trick, skip/xfail, or leaf-specific threshold change is acceptable.

[seonghobae]

Additional Rust-owned canary from ContextualWisdomLab/fast-mlsirm#1722.

Predecessor exact head 28b0305595107fd0ba21d7b27c1ac5db68ae8bf1 reached central OpenCode run 34091658473, where product review completed but coverage-evidence job 101708903896 failed at Enforce changed-line coverage; the retained opencode-coverage-source artifact has since expired. Fresh source review found one genuinely impossible Rust branch (CovarianceStandardizationError::NonFiniteResult after exact c² <= v_i*v_j admission) plus an impossible checked_shl fallback. Rather than synthesize an unreachable test or touch Python, fast-mlsirm removed those impossible branches and added reachable Rust edge tests at exact new head 66a333fb50a728b96fb4a109361d9bc1f311db3c (including dimension.checked_mul overflow and all remaining public error-display arms).

This is a useful acceptance canary for #2099: central required coverage should now measure exact-head owned Rust line and branch/edge execution for crates/mlsirm-core/src/covariance_standardization.rs, and if it is below contract it should report exact Rust misses. A Python-only receipt, expired-source artifact, or generic percentage must not certify this numerical PR.