[Karib0u]

Fixes a mistake in #785.

The problem

#785 set add-rust-environment-hash-key: false so the runner image's preinstalled toolchains (some images ship Rust 1.99.0 next to our 1.98.1) would stop splitting each cache key. In rust-cache v2.9.2 that option gates both the toolchain hash and the lockfile hash (src/config.ts lines 129 and 156). Every key is now static, for example v0-rust-test-linux-Linux-x64 on run 38778998481, so:

• it hits exactly forever, and rust-cache skips saving on an exact hit, so the cache is frozen at its first save;
• a Cargo.lock, manifest or rust-toolchain.toml bump never refreshes it, so builds would drift colder with every dependency or toolchain update.

#785's description said a toolchain bump still changes the key. That was wrong.

The fix

• Back to rust-cache's default hashing (toolchains, env and lockfiles).
• Remove the split at its source: a Keep only the pinned toolchain step before each cache uninstalls every toolchain except the rust-toolchain.toml channel, so rustup toolchain list shows only the pin. Tested locally against Windows \r output, the nothing-to-remove case and an extra 1.99.0.
• ebpf-build is unchanged: it needs its pinned nightly and already used the default hashing.
• save-if main-only and the per-kernel ebpf-load key from ci: stop rust-cache misses from runner image rollouts #785/ci: shorten the PR critical path #786 stay.

Expected

Keys change once more, so the first main run after merge is cold and every later run is warm. A lockfile bump then gets a new key with a fallback to the previous cache. zizmor --offline is clean.