bcr_presubmit vendor step uses USE_BAZEL_VERSION=latest, ignoring presubmit.yml matrix

[smolkaj]

Summary

bcr_presubmit.py's prepare_test_module_repo runs bazel vendor
with USE_BAZEL_VERSION=latest, regardless of the Bazel version
specified in the module's presubmit.yml matrix. This causes module
graph resolution failures for modules whose transitive deps are
compatible with their declared Bazel version but not with latest.

Reproducer

A module declares bazel: ["8.x"] in presubmit.yml and depends on
grpc@1.80.0. grpc declares rules_swift@2.5.0 (compatibility
level 2). On Bazel 9, bazel_tools bundles rules_swift@3.1.2
(compatibility level 3), so module resolution fails:

ERROR: Error computing the main repository mapping: grpc@1.80.0
depends on rules_swift@2.5.0 with compatibility level 2, but
bazel_tools@_ depends on rules_swift@3.1.2 with compatibility
level 3 which is different

This doesn't happen on Bazel 8 (whose bazel_tools doesn't depend
on rules_swift at all), which is the version the module actually
targets.

Hit while submitting fourward@20260405.1 (#8183).
Failing CI run: https://buildkite.com/bazel/bcr-presubmit/builds/32035

Proposed fix

Use the Bazel version from the presubmit.yml matrix for the vendor
step, not latest. The vendor step resolves the module graph, which
is version-sensitive — using a different Bazel version than the build
defeats the purpose of the matrix.

Workaround

Submit a BCR patch for the transitive dep (grpc) that bumps
rules_swift, even though the module itself works fine on the declared
Bazel version.