ci: shard the Windows OpenVMM VMM tests across WHP runners #691

Parent: #430, workstream 2. Blocked by: #690.

Summary

Run the Windows OpenVMM VMM tests in at least two duration-balanced shards on separate WHP runners, from the content that #690 builds once.

Today

• The Windows/WHP VMM-test job finished last in 11 of the 14 runs without queueing of CI: maximize workflow parallelism and reduce turnaround time #430's baseline, with a median duration of 20.4 minutes.
• Test execution is already parallel within the job. In reference run 39585909588, Nextest ran the 29 selected tests in 283 seconds. In run 37635396339, which CI: maximize workflow parallelism and reduce turnaround time #430 was filed against, their individual durations summed to 821 seconds.
• The WHP pool has eight general runners (ci: dedicate the benchmark runners to the platform jobs #649).
• OpenVMM CI: enable remaining backend-native VMM tests #135 would add tests to these filters.

Tasks

• Derive duration-balanced filters from the tests' recorded durations, and run at least two shards on separate WHP runners.
• Choose the shard count from ci: build the OpenVMM VMM tests once per target and hand them to the backend jobs #690's transfer measurements and the per-test durations, and don't shard if the transfer outweighs the gain.
• Fail when a selected test matches no shard or more than one.
• Give every shard unique failure-diagnostic artifact names, including the shard, run ID, and attempt.
• Aggregate the shards into the required status, release, and performance-persistence gates.
• Shard the Linux consumers too if they become the longest OpenVMM lane.

Acceptance criteria

• The shards together run exactly the tests of the unsharded filter.
• The gates fail closed when any shard fails or is skipped unexpectedly; fork, draft, path-filter, cancellation, and rerun behavior is unchanged.
• Timing and WHP queue time from at least five comparable runs; an extra shard must not just add queueing.
• doc/ci.md describes the shards.