materialize_base_rust_toolchain.py reads the merge tree instead of PR_BASE_SHA #1118

Summary

Unlike its siblings materialize_base_python_requirements.py and
materialize_base_javascript_packages.py, which take an explicit
--base-sha "$PR_BASE_SHA" and read blob content at that revision via
git show <sha>:<path>, materialize_base_rust_toolchain.py takes no
revision argument and reads Cargo.toml / Cargo.lock /
rust-toolchain* directly off the filesystem
(COVERAGE_SOURCE_WORKDIR), which is a merge of the base checkout with
the PR head already applied.

This means a PR that modifies its own Cargo.toml / Cargo.lock can
influence what the coverage sandbox's "base" Rust toolchain image
materializes and prefetches — the base-revision pin the Python/JS
materializers already enforce doesn't hold for Rust.

Flagged by CodeRabbit on #1052
(.github/workflows/opencode-review-dispatch.yml:638, "Heavy lift").

Why deferred out of #1052

• This repository has no Cargo.toml, so the bug doesn't affect this
  repo's own coverage evaluation — it only affects sibling Rust repos.
• Fixing it properly means mirroring the sibling _git() /
  git show <base_sha>:<path> pattern throughout
  materialize_base_rust_toolchain.py (tracked-path listing, TOML
  reads, workspace-member glob expansion, and the file-copy step all
  currently assume filesystem access), plus a full rewrite of
  tests/test_materialize_base_rust_toolchain.py's fixtures from
  plain temp directories to real git repos with commits. That's a
  separate, focused change, not a quick-win fix to bundle into fix(opencode): split review surfaces, give NIM two hours, and remove GitHub Models #1052.

Suggested fix

Add a required --base-sha argument, validate it with the existing
SHA_RE pattern used elsewhere in scripts/ci/, and read
Cargo.toml / Cargo.lock / rust-toolchain.toml / rust-toolchain
/ workspace member manifests via git ls-tree + git show <base_sha>:<path> instead of Path.is_file() / Path.read_text(),
mirroring materialize_base_python_requirements.py's _git() helper.