ci: restore a red main — refresh the conformance negative control and formatting

[justinchuby]

main's two required checks are both red, and neither failure is a real finding. This restores them.

1. Rust quality + Fast: formatting drift

cargo fmt --all --check failed on onnx-runtime-ep-cuda/src/optimizer.rs, then on kernels/normalization.rs and matmul_nbits.rs. Ran cargo fmt --all; no logic touched.

2. EP conformance: a negative control that went stale

The harness keeps one real ONNX op the EP declines, to prove the decline path still works. That op was Celu — and the CPU EP has since grown a Celu kernel, so the control started reporting expected UNSUPPORTED, got PASS.

The control was working, not failing. It detected exactly what it exists to detect; nothing is wrong with the EP. Moved it to Det (verified: reference evaluates to -2.0, runner returns rc=2 UNSUPPORTED_OP … no handler for ai.onnx::Det), and added a hint so the next person to hit this reads "your EP grew a kernel" instead of "conformance is broken".

3. Fast: the MLAS-free gate could not run its probe

Unmasked once formatting was fixed — it had never been reached.

The gate asks cargo metadata --offline for the whole workspace resolve, and by design fails loud rather than skipping when it cannot read one (a probe that cannot run must not report a pass — correct design). But the Linux lanes build a subset of the workspace, so only that subset's packages reach the registry cache. base64 v0.13.1 is reachable only through tokenizers, which no subset crate builds.

Result: an --offline download failure for a crate with no connection to MLAS turned the gate red.

Verified causally, not by inference — evicted exactly base64-0.13.1 from the local registry:

	probe result
cache complete	rc=0, 7/7 pass
base64-0.13.1 evicted	rc=101, byte-identical to the CI failure
after cargo fetch --locked	rc=0, downloads exactly that crate

Added cargo fetch --locked to both Linux lanes. This keeps the probe hermetic and the gate strict — the alternative (letting an unrunnable probe skip) would convert a required merge gate into no gate at all.

The gate's logic and strength are unchanged. I only added the remedy to its failure message, and confirmed both directions: it still fails loud when it cannot run, and it now names the cause.

Scope

#1173's MLAS research work is not otherwise touched — no gate logic, thresholds or coverage changed.

Verification

• default_artifacts_are_mlas_free 7/7 · hint fires only on the offline-download failure
• python -m unittest conformance.test_run_onnx_tests 5/5 · new control end-to-end status: UNSUPPORTED, failures: []
• cargo fmt --all --check clean · clippy clean · ci.yml parses

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.77%. Comparing base (70db811) to head (9fae9d2).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1578       +/-   ##
===========================================
- Coverage   82.64%   80.77%    -1.88%     
===========================================
  Files          12      381      +369     
  Lines        5475   173645   +168170     
  Branches     5475   173645   +168170     
===========================================
+ Hits         4525   140265   +135740     
- Misses        757    28490    +27733     
- Partials      193     4890     +4697     

Flag	Coverage Δ
cli-ort-linux	82.60% <ø> (ø)
cli-ort-windows	82.19% <ø> (ø)
mlas	85.09% <ø> (?)
offline	80.63% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 369 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.