stabilize hosted-fork Bazel lanes after runner fallback fix

[dzianisv]

Summary

After fixing fork runner selection, Bazel now starts on hosted runners in dzianisv/codex, but two hosted lanes are still not viable:

• Intel macOS hosted Bazel fails with no matching C/C++ toolchain
• Linux musl hosted Bazel fails while fetching toml2json_linux_amd64 from GitHub releases with HTTP 502

This is separate from issue #28. Issue #28 was the scheduler/runner-label failure before step 1. These jobs now execute real steps and expose a new hosted-fork compatibility problem.

Evidence

PR #32 on 2026-03-17:

• Local Bazel build on macos-15-intel for x86_64-apple-darwin
  • error: No matching toolchains found for @@bazel_tools//tools/cpp:toolchain_type
• Local Bazel build on ubuntu-24.04 for x86_64-unknown-linux-musl
  • error downloading https://github.com/dzbarsky/toml2json/releases/download/v0.0.23/toml2json_linux_amd64
  • GET returned 502 Bad Gateway or Proxy Error

Important workflow detail:

• in .github/workflows/bazel.yml, matrix.target is currently metadata for the job name / one lockfile-check guard and is not passed into the bazel test //... command. So these failures are about the host runner environment, not about a real Bazel target selection mechanism.

Why this matters

Fork CI now has useful Bazel signal, but it still goes red on hosted lanes that are not yet compatible/reliable. We need an explicit fork policy instead of pretending those hosted lanes are production-ready.

Acceptance criteria

• define the intended Bazel policy for forks vs openai/codex
• either make hosted Intel macOS and hosted Linux musl Bazel stable, or exclude them from the fork-required matrix with documentation
• if host architecture remains only metadata, align the workflow naming/matrix with what Bazel is actually validating
• keep at least one meaningful Bazel lane for forks so CI still exercises Bazel end to end