Pin the Rust toolchain so a new compiler arrives as a pull request #270

This was generated by AI during triage.

What happened

CI installs floating stable Rust. On 2026-10-01 it moved from 1.98.1 to 1.99.0 between two pushes to main. The pull request for 362b9ca was green on 1.98.1; the same commit on main ran on 1.99.0 with an empty cargo cache (the cache key includes the compiler version) and went red, which failed the Runs on #262 and #263 as Inherited failures. The test that broke is being fixed in #269, but the same thing will happen with the next new lint, changed default or cold cache: main can go red with no commit to blame, and every Run on it fails.

Agent Brief

Category: enhancement
Summary: Pin the Rust toolchain in the repository, so a new compiler arrives as a pull request with its own CI.

Current behavior:
The CI workflow's jobs and the crates.io publish workflow install stable at whatever version is current when the job starts. Nothing in the repository records a toolchain version. A release of Rust changes what CI builds with on the next run, on main and on every open pull request at once.

Desired behavior:
The repository names one exact Rust version, in the standard toolchain file at its root, with the components CI needs (rustfmt, clippy). Every workflow that builds or tests the crate, and a contributor's cargo in a checkout, use that version. Moving to a newer Rust is a change to that file, reviewed and run through CI like any other.

The pin starts at the stable version current when this is implemented, with CI green on it.

Say in the contributor-facing docs how the pin is moved. If an update bot supports the toolchain file for this repository's setup, configuring it to open those pull requests is in scope; check that it does before relying on it, and if it does not, a documented manual bump is enough.

Key interfaces:

• The toolchain file at the repository root: new.
• The CI workflow's test and test-macos jobs and the publish workflow's build: install the pinned version instead of stable, without naming the version a second time if that can be avoided.
• The release workflow: confirm what toolchain it builds with once the file exists, and say so in the pull request.
• The crates.io package: the toolchain file must not change what cargo install thirdshift builds with or needs; the packaging tests say what the package carries.

Acceptance criteria:

• The repository root has a toolchain file naming an exact version and the rustfmt and clippy components.
• CI's logs show test and test-macos building with that version.
• No workflow that builds or tests the crate installs floating stable.
• The docs say how to move the pin.
• cargo fmt --check, cargo clippy --all-targets -- -D warnings and the tests pass on the pinned version.

Out of scope:

• Declaring a minimum supported Rust version for users of the crate.
• Fixing the packaging test that needs a warm cargo cache (The OpenSSL dependency test fails on a cold cargo cache, leaving CI red on main #269).
• Changing the runner images or the cache action.