ci: pin the Rust toolchain - a floating stable turned every PR red

[gHashTag]

ci.yml used dtolnay/rust-toolchain@stable. Combined with cargo clippy --all-targets -- -D warnings, that makes every future Rust release a potential hard failure of this gate - with no commit here to cause it, and nothing to point at when it fires.

It fired. Stable gained clippy::chunks_exact_to_as_chunks, and tests/sha256_kat_anchor.rs uses chunks_exact at lines 102 and 184. build + test (-sim baseline) now fails in 18 seconds on every pull request, including a README-only one. ci on main was green as recently as 2026-08-09, so nothing in this repository changed - the ground did.

Verified, not argued

Pinned to 1.96.0 and checked by running the gate's own four commands against that exact toolchain:

rustc 1.96.0 (ac68faa20 2026-05-25)
cargo fmt --all --check                    exit 0
cargo clippy --all-targets -- -D warnings  exit 0
cargo build                                exit 0
cargo test                                 exit 0, 0 failed

Bumping the toolchain is now a deliberate act with a diff, which is the point.

Deliberately not done here

No rust-toolchain.toml. The drift-guard job runs rustfmt inside this working directory to normalise both sides of its comparison, so a toolchain file would silently change which rustfmt that gate uses. That gate is currently red for an unrelated reason (below), and changing two variables at once on a red gate destroys the ability to tell which one moved it.

The three other workflows keep @stable. Each builds t27c from gHashTag/t27, and I cannot verify here that t27c's bootstrap compiles under 1.96.0. Pinning them on an unverified assumption would trade one floating failure for a possible hard one.

This fixes one of three red required checks

The other two are pre-existing, and a Rust pin cannot reach them. Both trace to the same disease this PR treats - a floating upstream:

Check	Cause	Fixable by a Rust pin?
build + test (-sim baseline)	floating stable + new clippy lint	yes - this PR
drift check (68 specs x 3 backends)	builds t27c from gHashTag/t27 at ref: master; every committed gen/rust artifact now disagrees with that compiler's output	no - needs a regeneration wave; the gate is doing its job
GF-T spec KATs under Icarus Verilog	iverilog rejected generated Verilog, also from upstream t27c output	no

main therefore cannot take any merge today, regardless of content - which is worth knowing independently of this PR.

phi^2 + phi^-2 = 3

🤖 Generated with Claude Code