bazel: materialize configured test shards

[anp-oai]

Why

Windows Bazel profiling in #31339 and #31367 showed that heavy sharded Rust test labels still form the long pole because GitHub assigns the entire Bazel label to one runner. For example, core-all-test-windows-cross keeps all 16 internal test shards on one host, where most critical-path time is spent waiting for local test resources.

Materializing configured test shards as first-class Bazel targets lets the existing GitHub target selection distribute those shards across Windows runners while preserving the current canonical labels for local use.

What

• make every test_shard_counts entry generate one workspace_root_test leaf per stable libtest bucket
• keep the original target name as a test_suite over those leaves
• pass fixed shard count/index values through the workspace-root launchers instead of Bazel's internal shard_count
• keep each leaf flaky so retry behavior remains per shard
• keep all leaves pointed at the same underlying Rust test binary so RBE build/cache reuse is unchanged

Manual validation

• bazel query 'tests(//codex-rs/core:core-all-test-windows-cross)' --output=label returns 16 shard targets
• bazel test //codex-rs/exec:exec-all-test-shard-1-of-8 --test_output=errors
• bazel test //codex-rs/exec:exec-all-test --test_output=errors runs and passes all 8 suite members
• just argument-comment-lint