[CI]: pin Rust toolchain to 1.98.1 via rust-toolchain.toml

[x15sr71]

In raising this pull request, I confirm the following (please check boxes):

Reason for this PR:

• This PR adds new functionality.
• This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists.
• This PR is porting code from C to Rust.

Sanity check:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• If the PR adds new functionality, I've added it to the changelog. If it's just a bug fix, I have NOT added it to the changelog.
• I am NOT adding new C code unless it's to fix an existing, reproducible bug.

Repro instructions:

CI-only change, so no media sample — the repro is the failure history: format_rust goes red on unrelated PRs every rustc release (#1706, #1753, #1758, #2332), most recently hitting #2327 and #2298.

---

Background

format.yml runs cargo clippy -- -D warnings on toolchain: stable, which floats to whatever rustc is newest on the day CI runs. Every stable release adds lints, so a new rustc turns format_rust red on every open PR, regardless of what those PRs changed.

It has needed a dedicated fix PR almost every release: #1706 (1.88), #1753 (1.90), #1758 (1.91), and most recently #2332 for needless_late_init on 1.98.

The side effect is the one #2332 describes: authors fix shared-code lints inside unrelated PRs just to go green. #2298 carried a style(rust): ...satisfy clippy byte_char_slices commit in an unrelated report fix; #2327 (C-only, no Rust touched) failed clippy purely on master's lint. As #2332 puts it: "a lint fix on shared code should land once, on its own." This PR makes that the default instead of something to be arranged.

What this changes

rust-toolchain.toml at repo root, pinning channel = "1.98.1" — the current stable, so this is not a rollback: it changes nothing about what CI runs today, it only stops the version from moving on its own. Bumps become deliberate PRs where new lints are fixed once, together, rather than surprising every open PR.

• components = ["rustfmt", "clippy"] — supplied by the file, so the workflow no longer has to request them.
• targets = [...MSVC triples] — required: windows/rust.bat always builds with cargo build --target, and .vcxproj uses i686-pc-windows-msvc for Win32. The toolchain action installs targets onto the toolchain it installed, not onto the pinned one, so the target std has to come from the file.

actions-rs/toolchain@v1 → dtolnay/rust-toolchain@stable (4 workflows). This is required, not cosmetic: those steps set override: true, i.e. rustup override set stable. A directory override outranks rust-toolchain.toml in rustup's precedence, so with it in place the pin would be silently ignored and clippy would keep running on floating stable. dtolnay/rust-toolchain only sets the default toolchain, which the file correctly outranks. (actions-rs/* has also been archived and unmaintained since 2022; the other five workflows already use dtolnay.)

Dependabot — package-ecosystem: rust-toolchain, so a new rustc arrives as a reviewable PR instead of arriving unannounced in everyone's CI.

Path filters — rust-toolchain.toml added to format.yml and test_rust.yml. Without this a Dependabot bump (which touches only that file) would match no path filter, so clippy and the tests would not run and the bump would merge unvalidated — reintroducing the same problem through the back door.

Testing

• The pinned version is the current stable (1.98.1, released 2026-09-01), and format_rust on master is already green on it — the upstream runs after that release succeeded. So CI behaviour on x86_64 is unchanged by this PR; only the drift stops.
• Toolchain resolution verified against a real rustup (rustup 1.29, aarch64 Linux): with stable installed and set as default — the state CI is in after the toolchain action runs — rustup reports 1.98.1-... (overridden by '.../rust-toolchain.toml'), and installs rustfmt + clippy and both MSVC targets from the file. cargo check --target i686-pc-windows-msvc resolves.
• Inverse confirmed: applying rustup override set stable flips the active toolchain to stable ... (directory override) — i.e. the old override: true did defeat the file. Removing it is what makes the pin effective.
• cargo clippy -- -D warnings and cargo fmt --all -- --check clean on both workdirs (src/rust, src/rust/lib_ccxr), macOS aarch64.
• TOML/YAML parse-checked; the CMake MSRV gate (1.87.0) is satisfied.