Shard Bazel Windows tests across jobs

[starr-openai]

Summary

• split the single PR-blocking Bazel Windows test leg into four Windows shard jobs
• preserve the existing required Windows Bazel check name with a lightweight aggregate gate
• keep Linux/macOS Bazel test jobs and the separate Windows clippy/release jobs unchanged

Why

The ordinary PR Windows Bazel test leg was one GitHub Actions job, so Bazel only had in-job parallelism. This gives that lane real job-level fanout across separate Windows hosts while keeping the target set disjoint via stable label hashing.

Evidence

• final pre-rebase green run: 25774733562
• Windows shard target counts: 61/212, 48/212, 52/212, 51/212
• Windows test fanout completed in about 7m29s versus a recent monolithic median around 22m26s

Notes

• this is scoped to the Bazel Windows test leg only
• each shard keeps the existing Windows cross-compile/RBE path and restores the former monolithic Windows test cache
• shard jobs do not upload duplicate repository caches after test work, keeping cache cleanup off the PR-blocking shard path
• no local validation run; relying on GitHub Actions for the workflow-shaped check

[bolinfest]

TYSM!