fix(ci): restore both required checks — migrate to as_chunks for Rust 1.98, reformat main

[justinchuby]

Both required checks are currently red on pristine main

This is not caused by any one branch. On 0da1fe0bd, with a clean checkout:

• Fast (Linux x86_64) — Rust 1.98.0 was released on 2026-08-18 and
  added clippy::chunks_exact_to_as_chunks to the default set. CI installs
  unpinned stable (rustup toolchain install stable, ci.yml:126), so the lint
  arrived on its own. The clippy gate runs -D warnings, and there were 70
  hits across 28 files, so every PR in the repo now fails this check.
• Rust quality — cargo fmt --all -- --check fails: feat(native-decode): commit recurrent GDN state to accepted prefix in speculative decode #1598 landed six files
  unformatted (decode/mod.rs, decode/state.rs, native_decode/{cuda,mod,tests}.rs).

I found this while trying to get Fast green on an unrelated PR of mine. It
blocks everyone, so it is fixed here.

Why migrate rather than pin or allow

docs/architecture/DESIGN.md:818 states the policy explicitly:

| MSRV | Latest stable | No old Rust version compat needed |

Pinning the toolchain would contradict that, and a blanket
allow(chunks_exact_to_as_chunks) would suppress a lint that is pointing at
real code quality. So the code is migrated.

What the migration actually does

as_chunks::<N>() yields &[T; N] where chunks_exact(N) yielded &[T]. That
has a pleasant consequence: the fallible conversions call sites had to perform
are not merely redundant afterwards, they no longer type-check. So most of
this diff is deleting them:

-.map(|bytes| f32::from_le_bytes(bytes.try_into().unwrap()))
+.map(|bytes| f32::from_le_bytes(*bytes))

Each one removed a panic! branch that could never fire. onnx-runtime-comm's
reductions, onnx-runtime-ep-cpu's quantization/qlinear paths,
onnx-runtime-shape-inference, onnx-std and the session tests all shed one.

Where the old code used ChunksExact::remainder(), as_chunks returns the
remainder as .1, so the iterator no longer has to be threaded through
by_ref() and then re-consulted:

-let mut weight_chunks = weight.chunks_exact(LANES);
-let mut activation_chunks = activation.chunks_exact(LANES);
-for (w, a) in weight_chunks.by_ref().zip(activation_chunks.by_ref()) { ... }
-for (w, a) in weight_chunks.remainder().iter().zip(activation_chunks.remainder())
+let (weight_chunks, weight_tail) = weight.as_chunks::<LANES>();
+let (activation_chunks, activation_tail) = activation.as_chunks::<LANES>();
+for (w, a) in weight_chunks.iter().zip(activation_chunks) { ... }
+for (w, a) in weight_tail.iter().zip(activation_tail)

(dot_u8_f32 in matmul_nbits.rs, and PipelineCacheKey::absorb in
onnx-genai-engine, which is a hash — the chunk sequence and the remainder
handling are unchanged, so the digest is unchanged.)

One genuine false positive is annotated, not changed. onnx-runtime-ir's
read_vec_le chunks by T::BYTE_SIZE, an associated const of a generic
parameter, which is not permitted as a const generic argument on stable —
clippy's own suggestion does not compile there. It carries an #[allow] with a
reason.

Two hazards worth flagging, since this was partly mechanical

1. Clippy's suggestion for chunks_exact_mut is as_chunks_mut::<N>().0.iter(),
   which silently drops the mutability the call site needs. Applying it verbatim
   would not compile in onnx-runtime-comm::reduction (the loop body calls
   copy_from_slice). Every mutable site uses .iter_mut() here.
2. One pass is never enough. A chunks_exact inside the same expression as
   another is masked until the first is fixed, so the migration was driven to a
   fixed point and the gate re-run from a forced-fresh analysis (clippy caches
   diagnostics, and an unchanged tree reports nothing on a second run — which
   will happily look like success over a dirty tree).

Local validation

The exact CI clippy command (all 30 crates, --all-targets -- -D warnings)
is clean, as is the same gate over onnx-genai-cli, onnx-genai-engine,
onnx-runtime-ep-plugin and onnx-runtime-ep-cpu-plugin. cargo fmt --all --check
is clean.

Tests, on stable 1.98.0:

suite	result
onnx-runtime-ep-cpu --lib	1551 passed, 0 failed
onnx-runtime-ep-plugin --lib	310 passed
onnx-runtime-ep-cpu-plugin --test plugin_ort_e2e --include-ignored	57 passed (ORT conformance)
onnx-runtime-session	all suites ok
onnx-genai-engine --lib	433 passed
onnx-runtime-comm, -ir, -shape-inference, -eager, -capi, onnx-std, onnx-genai-preprocess	all ok
aarch64 (aarch64-unknown-linux-gnu under qemu) onnx-runtime-ep-cpu --lib	see below

The kernel crates are where the numeric risk is, and 1551 kernel tests plus the
57-case ORT conformance run cover it.

Note on scope

This touches crates outside my usual area (onnx-runtime-comm, onnx-std,
onnx-genai-engine, onnx-runtime-session, onnx-runtime-shape-inference,
onnx-runtime-capi, onnx-genai-preprocess). That is not empire-building — the
gate is all-or-nothing, so Fast cannot go green for anyone until every hit is
addressed. The changes there are mechanical and each is covered by that crate's
own tests.

---

Independent review found a BLOCKER, now fixed

Reviewed adversarially (Opus, independent context). It found a real defect I had
missed, and it is the interesting kind:

The PR migrated every hit that appears under the default feature set, but
native_decode/native_component are #[cfg(feature = "native-backend")] and
are never compiled by the default clippy lanes. Rust quality has a dedicated
step for exactly that (ci.yml:416), so ten more sites kept that gate red.

That step exists because of a previous incident — its comment says "without this
step a refactor can leave it uncompilable while every other job still passes".
It caught me the same way. Fixed in 83d7bc9ee, along with a second new-1.98
lint the same step exposes, clippy::manual_slice_fill, in native_decode/cuda.rs
(clippy's suggestion there, &mut self.row_lens.fill(..), is malformed — the
borrow is not wanted, self.row_lens.fill(..) is).

Lesson recorded: for a lint migration, "clean under default features" is not the
gate. Every feature-gated lane has to be run.

The review verified and found no behavioural regression in the rest, in
particular the two sites I was most concerned about:

• PipelineCacheKey::absorb (a cache-key hash) — same 8-byte words in the
  same order, same zero-padded tail, so the digest is unchanged and cache keys
  stay stable.
• reduction.rs — mutability preserved (iter_mut, not clippy's suggested
  iter); confirmed by running the crate's own falsifiers, including
  distributed_all_reduce_matches_single_device_bitwise, which a non-mutating
  iterator would turn into a no-op.

It also confirmed dot_u8_f32's tail arithmetic, that every dropped try_into()
was a genuine &[T; N] → [T; N], that the read_vec_le #[allow] justification
is true, that the reformatting commit is formatting-only, and that the ARM sweep
test's covered is unchanged.

Full local validation

Gates, all on stable 1.98.0 (installed locally to match CI — my default was
1.97.1, which is precisely why I could not see this lint at first):

gate	result
Fast clippy (30 crates, --all-targets -- -D warnings)	clean
Rust quality clippy (same set)	clean
clippy -p onnx-genai-engine --features native-backend	clean
clippy onnx-genai-cli, onnx-runtime-ep-plugin, onnx-runtime-ep-cpu-plugin	clean
cargo fmt --all -- --check	clean
scripts/check_cross_compile.sh (x86_64 + real aarch64 pass)	pass
the nine Rust quality python gates (publish order, dispatch manifest/reachability, feature-gate coverage, env vars, …)	9/9 pass

Tests:

suite	result
onnx-runtime-ep-cpu --lib	1551 passed, 0 failed
same, aarch64 under qemu	1455 passed, 0 failed
onnx-runtime-ep-cpu --features mlas kernels::moe::	19 passed
onnx-runtime-ep-cpu --features mlas kernels::qlinear_matmul::	30 passed
onnx-runtime-ep-cpu --features mlas registry config	1 passed
onnx-genai-engine --lib --features native-backend	567 passed
onnx-genai-engine --lib	433 passed
onnx-runtime-ep-cpu-plugin --test plugin_ort_e2e --include-ignored	57 passed (ORT conformance)
onnx-runtime-ep-plugin --lib	310 passed
onnx-runtime-session, -comm, -ir, -shape-inference, -eager, -capi, onnx-std, onnx-genai-preprocess	all ok

Disclosure of missing scope: onnx-genai-engine's integration test binaries
(iterative_pipeline_e2e, vlm_pipeline_e2e, …) could not be linked locally —
the build host's disk is shared and repeatedly hit 100%, and ld died with a bus
error. The library tests for that crate ran (567 with native-backend, 433
without) and cover the changed code; CI will link the rest. No local red anywhere.

---

Why main looks green when it is not

Worth recording, because it misled me for a while and will mislead the next
person: Fast is passing on main right now, on rustc 1.98.0, with 108
chunks_exact sites still in the linted crates.

It is passing because its clippy step never checked those crates. The step
compiled 244 crates from a restored cache, and onnx-runtime-ir,
onnx-runtime-ep-cpu and onnx-runtime-comm are not among them — they were
already fresh, and cargo does not re-emit diagnostics for a crate it did not
rebuild. The lint is a default-warn lint promoted by -D warnings, so a
cached crate is indistinguishable from a clean one.

The moment a crate is genuinely re-checked, it fires. That is exactly what
happened on #1587, whose log shows the error arriving on the line after
Checking onnx-runtime-ir. So the situation is not "main is fine and this PR is
cleanup" — it is that main is one cache eviction away from a repo-wide outage,
and in the meantime every PR that touches one of these crates goes red for a
reason that has nothing to do with its own change.

Both my own PRs died this way before I understood it.

---

Second blocker found while landing this: a bf16 route assertion (now fixed on main)

Fast on this PR then failed in a place my diff does not touch (matmul.rs,
zero lines changed):

BFloat16 m=2: prefill did not take the fused widen-pack GEBP
  left: 0
 right: 1

half_prefill_gebp_agrees_with_the_blocked_half_gemm_and_is_the_route asserted
that bf16 prefill takes the fused widen-pack GEBP. On any host with AVX-512
BF16 it does not: half_gemm_tile hands bf16 to the native microkernel and
returns before the GEBP is reached, so the route counter is legitimately 0. The
f16 arm has no such interception, which is why only the bf16 rows failed.

My CPU has no AVX-512 at all, so it passed locally and failed on runners that
have the faster kernel -- deterministic per runner, indistinguishable from
flake across a heterogeneous pool. Confirmed rather than argued: forcing the
bf16 early return on my host reproduced the CI panic verbatim, including
m=2 and left: 0.

I fixed it here, and then a fix for the same defect landed on main while this
PR was in the queue. Main's is better -- it derives the expectation from the
very predicates half_gemm_tile dispatches on, instead of restating the
hardware assumption, and it treats the no-AVX2 host as a legitimate (0, 0)
rather than a skip. So I took main's version wholesale and dropped mine; this
PR now carries no change to matmul.rs at all. Recording the diagnosis here
anyway, since the reproduction is the part that was expensive.

Re-validated after taking main's version: ep-cpu 1555 passed on x86_64,
1455 passed, 0 failed on aarch64 under qemu, ORT conformance 57 passed,
engine --features native-backend 568 passed; fmt and every clippy gate
still clean.

[codecov]

Codecov Report

❌ Patch coverage is 92.26190% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.97%. Comparing base (fd4c580) to head (20cd9ea).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...es/onnx-runtime-ep-cpu/src/kernels/quantization.rs	50.00%	8 Missing ⚠️
...onnx-std/src/check/rules/tensor_sparse_payloads.rs	0.00%	4 Missing ⚠️
crates/onnx-runtime-session/src/fp16_decode.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1603      +/-   ##
==========================================
- Coverage   81.53%   80.97%   -0.57%     
==========================================
  Files         383      383              
  Lines      179169   179249      +80     
  Branches   179169   179249      +80     
==========================================
- Hits       146084   145138     -946     
- Misses      28145    29173    +1028     
+ Partials     4940     4938       -2     

Flag	Coverage Δ
cli-ort-linux	82.60% <100.00%> (+<0.01%)	⬆️
cli-ort-windows	82.20% <100.00%> (+<0.01%)	⬆️
mlas	85.12% <ø> (+0.03%)	⬆️
offline	80.84% <92.12%> (-0.60%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
crates/onnx-genai-cli/src/transcribe.rs	78.82% <100.00%> (+0.09%)	⬆️
crates/onnx-runtime-comm/src/inprocess.rs	90.64% <100.00%> (+0.08%)	⬆️
crates/onnx-runtime-comm/src/reduction.rs	88.57% <100.00%> (+1.37%)	⬆️
crates/onnx-runtime-eager/src/tensor.rs	81.57% <100.00%> (+0.39%)	⬆️
...s/onnx-runtime-ep-cpu/src/kernels/block_dequant.rs	79.32% <100.00%> (ø)
...-ep-cpu/src/kernels/compressed_sparse_attention.rs	73.61% <100.00%> (+0.01%)	⬆️
...s/onnx-runtime-ep-cpu/src/kernels/contrib_fused.rs	89.57% <100.00%> (ø)
...tes/onnx-runtime-ep-cpu/src/kernels/log_softmax.rs	87.09% <100.00%> (ø)
...es/onnx-runtime-ep-cpu/src/kernels/matmul_nbits.rs	78.70% <100.00%> (-5.55%)	⬇️
crates/onnx-runtime-ep-cpu/src/kernels/mod.rs	95.08% <100.00%> (+0.04%)	⬆️
... and 13 more

... and 9 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.