Add Windows ARM64 cross-compiled archive path

[starr-openai]

Why

Windows ARM64 full-CI test shards currently each build their own ARM64 test binaries on native ARM64 runners before they can start running tests. That makes the ARM64 test path spend most of its critical path rebuilding the same artifacts four times.

This PR changes that path to build the Windows ARM64 nextest archive once on an x64 Windows runner, then fan the uploaded archive out to the ARM64 test shards.

What changed

• add a Windows ARM64 nextest archive producer in rust-ci-full.yml
• keep the existing ARM64 shard matrix, but run those shards from the uploaded archive when archive mode is enabled
• add the MSVC ARM64 environment/linker setup needed for the x64 -> ARM64 archive build
• create the nextest extract directory before archive extraction on ARM64 shards

Latency

Measured against the earlier direct ARM64 shard path:

• old path: earliest ARM64 shard start 00:11:43Z, last ARM64 shard finish 00:53:49Z -> 42m06s critical path
• new archive path: archive producer start 22:51:05Z, last ARM64 archive shard finish 23:15:57Z -> 24m52s critical path
• net improvement: 17m14s faster, about 41% lower ARM64 test critical path

The archive producer itself took 14m08s; once the archive was available, the four ARM64 archive shards completed in 7m07s, 5m33s, 6m18s, and 7m26s.

Validation

• current-head ARM64 archive probe: https://github.com/openai/codex/actions/runs/25890163429
• on 8718dfc9d9ddfd911a5fae2d57159e26ed606f4b, Build Windows arm64 nextest archive and all four Windows ARM64 archive shards succeeded

Stack

• base: starr/windows-ci-arm64-shards-4-full-ci
• this PR owns the cross-compiled archive layer on top of that shard split

Notes

• the manual full probe still has unrelated Linux test failures outside the Windows ARM64 archive path

How it works

The workflow keeps the existing Windows ARM64 shard shape, but separates compilation from test execution. Instead of having each native ARM64 shard build the same test binaries before running its partition, one x64 Windows job cross-compiles the ARM64 nextest archive once and uploads it as an artifact.

The workflow then fans that archive back out to the Windows ARM64 shard jobs. Those jobs still run on ARM64 Windows runners and still use the same nextest partitioning, but they download the shared archive and invoke cargo nextest run --archive-file ... rather than rebuilding. --workspace-remap points nextest at the current checkout, and --extract-to gives each shard a local extraction directory for the archived binaries.

The MSVC setup action is what makes the producer possible: it configures an x64 Windows host with the ARM64 MSVC target environment, selects the right linker, and applies the small ARM64/lld compatibility shim needed for this cross-compiled archive path. The full-CI gatherer then treats the archive producer and archive-backed ARM64 shards as required workflow results, so the optimized path cannot fail silently.