ci: measure Windows Bazel test bottlenecks

[anp-oai]

Why

Measure what makes the Windows Bazel test shards slow under forced test execution, without treating shard assignment as the variable.

What

• bust selected test-action caches per uploaded commit with CODEX_BAZEL_TEST_CACHE_BUST=${GITHUB_SHA}
• collect 15-second CPU, processor-queue, disk, network, and memory counters
• upload full Bazel profiles
• compare the existing 4 local test jobs, RUST_TEST_THREADS=2, 8 local test jobs, and 12 local test jobs
• latest head is the terminal 12-way experiment, not a merge-ready configuration

Findings

• 4-way baseline: slow shard Bazel elapsed 835.5s; average CPU 25.3%
• two Rust harness threads: small and inconsistent movement
• 8 local test jobs: all shards improved; slow shard 609.3s (-27%), with average CPU 40.4%
• 12 local test jobs: regressed; slow shard 727.4s and processor queues reached the hundreds
• network throughput, disk latency, and available memory did not show sustained saturation; the avoidable bottleneck is the 4-way local test-action cap, with 8 near the observed knee

Manual validation

• yq '.' .github/workflows/bazel.yml
• git diff --check
• just test-github-scripts
• just fmt