fix(ci): stop the rust cache key fragmenting across runner images

The warm run added in #2446 was not restorable. It saved
v0-rust-browseros-agent-Linux-x64-77f289fb-... while a test job on the
same commit looked for ...-b588fbb1-..., so the restore key missed and
the job compiled from scratch.

shared-key removed the job name from the key, but rust-cache also folds
in a hash of the rust environment, and that hash is built from every
toolchain `rustup toolchain list` reports rather than the pinned one. The
runner image ships its own Rust next to the pinned 1.95.0, and that set
changes as images roll out, so identical configuration hashes differently
depending on which runner a job lands on.

It splits the existing caches almost evenly, which is why this was never
noticed as an outright miss:

  77f289fb   11 entries
  b588fbb1   11 entries
  two others  1 each

Half the jobs missed, and looked merely slow rather than broken.

Dropping that segment leaves the key as prefix, shared key, OS and arch,
and the lockfile hash, so dependency changes still bust it. Reuse across
toolchains stays safe because cargo fingerprints by rustc version itself
and rebuilds anything that does not match, rather than reusing artifacts
from a different compiler.

Both steps keep identical workspaces, shared-key, cache-directories and
toolchain pin, since all of them feed the key.

Author: DaniAkash

.github/workflows/test.yml

@@ -103,6 +103,14 @@ jobs:
           # Without this the key embeds GITHUB_JOB, so the warm cache produced
           # on main by a differently named job could never be restored here.
           shared-key: browseros-agent
+          # rust-cache hashes every toolchain `rustup toolchain list` reports,
+          # not just the pinned one, and the runner image ships its own Rust
+          # alongside it. That set changes as images roll out, so the key
+          # fragmented across runners and a warm cache was a coin flip. The
+          # lockfile hash still keys the cache, so dependency changes bust it;
+          # cargo fingerprints by rustc version itself, so a toolchain change
+          # rebuilds rather than reusing the wrong artifacts.
+          add-rust-environment-hash-key: false
           # Intermediate artifacts live outside the checkout so worktrees can
           # share them, and rust-cache only saves workspace target dirs plus the
           # registry and git caches by default. Name the build dir explicitly or

.github/workflows/turbo-cache-warm.yml

@@ -88,6 +88,14 @@ jobs:
           # Must match the Tests workflow exactly. Without it the key embeds
           # GITHUB_JOB and this cache would be unreadable there.
           shared-key: browseros-agent
+          # rust-cache hashes every toolchain `rustup toolchain list` reports,
+          # not just the pinned one, and the runner image ships its own Rust
+          # alongside it. That set changes as images roll out, so the key
+          # fragmented across runners and a warm cache was a coin flip. The
+          # lockfile hash still keys the cache, so dependency changes bust it;
+          # cargo fingerprints by rustc version itself, so a toolchain change
+          # rebuilds rather than reusing the wrong artifacts.
+          add-rust-environment-hash-key: false
           cache-directories: ~/.cargo/build/browseros
           # Save even though nothing here is a pass/fail gate; warming is the
           # entire point of the job.