Pin the toolchain this fork builds with (smr-moonshot#3675)

[isaacdoidge]

Fixes Entropy-Foundation/smr-moonshot#3675.

Why

Nothing in this fork declared a compiler, so the one used was whatever the machine happened to provide — and the set of toolchains that actually build it is both narrow and undeclared:

• the local rustup default, 1.87.0, is rejected outright (revm@29.0.0 requires rustc 1.88.0);
• 1.90.0, an approximation of a CI-era stable, fails to compile the branch;
• the workspace rust-version = "1.88.0" inherited from upstream therefore does not describe what this fork needs.

A contributor meets errors that read as code defects rather than environment ones, and a future move of stable can break the fork with no change on our side and nothing to pin back to.

What changed

rust-toolchain.toml pins 1.97.1, the version smr-moonshot and the aptos-core fork already pin, so this fork compiles under the toolchain its consumer uses. The file carries the components and the cross-compilation target the workflows ask for (clippy, rust-docs, rustfmt, riscv32imac-unknown-none-elf), because rustup installs those from the pin, and it states the divergence from upstream's MSRV explicitly so it reads as deliberate.

Two jobs genuinely need a different compiler, and both now set RUSTUP_TOOLCHAIN, which rustup ranks above rust-toolchain.toml:

• ci.yml's test matrix, which sweeps 1.88 / stable / nightly — without the override the pin would silently collapse all three onto one compiler and the MSRV would stop being tested at all;
• book.yml's build job, whose cargo doc invocation passes -Zunstable-options and so requires nightly.

That interaction is the one real hazard in adding a pin to an upstream-derived CI configuration, and it is worth knowing that dtolnay/rust-toolchain@… cannot be used to dodge it: that action sets rustup default, which rust-toolchain.toml outranks.

Verification

In a clean worktree at origin/feature/evm_automation plus this change:

• rustup show active-toolchain reports 1.97.1 (overridden by …/rust-toolchain.toml) on a machine whose default is 1.87.0 — i.e. the pin does what the issue asks, on a default that previously could not build the fork at all.
• cargo check -p revm -p revm-handler -p revm-precompile -p revm-context — clean. These are the crates the node consumes.

Two pre-existing failures are inherited, not introduced, and are unrelated to the toolchain (they reproduce identically at the same compiler without this change):

• cargo check --workspace --all-targets fails in revm-handler's test target — crates/handler/src/precompile_provider.rs:116, the trait bound [u8]: AsRef<[_; 0]> is not satisfied. This is dev-dependency feature unification pulling in winnow's AsRef<Bytes> for [u8] and AsRef<BStr> for [u8] impls, which makes the r.as_ref() there ambiguous. It is a genuine defect in the branch, independent of rustc version, and wants its own fix.
• cargo check --workspace additionally fails in a Solidity build step that needs solc and node_modules, which is an environment prerequisite rather than a code problem.

Separately worth knowing

While checking this I found that this fork's CI has never run. ci.yml, book.yml, bench.yml and ethereum-tests.yml all trigger only on main and release/**, but every fork PR since at least #36 targets feature/evm_automation. The Tests workflow has zero runs in the repository's history; the only workflow that has ever executed here is Dependabot's, and every one of those runs failed. So none of the workflow edits in this PR change any behaviour today — they keep the pin correct for whenever the workflows are enabled. Enabling them is a larger job than it looks, because the fork's clippy baseline is red, and it is worth tracking on its own.