Fix native Windows ARM64 compiler stack overflow on the executor restart fixture

[LunaStev]

Observed on PR #606 head 037baf248a9793be2b0563fb28972b5c4fb9714a (2026-09-12).

The native ARM64 job gets past LLVM allocator validation and basic GNU/MSVC code generation, then crashes while compiling the new async executor regression.

Failing job, step Run native ARM64 MSVC executor restart regression:

thread 'sockets_survive_executor_restart_and_release_their_completion_port' panicked at tests\runtime_regressions.rs:69:5:
async/executor_restart.wave compile:

thread 'main' has overflowed its stack

The assertion is on the compiler subprocess result, before the fixture executable is launched. No native IOCP restart result can be inferred from this failure.

Command selecting the failure:

cargo test --locked --test runtime_regressions --target aarch64-pc-windows-msvc --no-default-features --features llvm-target-aarch64 --jobs 2

The harness compiles tests/fixtures/async/executor_restart.wave with the debug native wavec and explicit aarch64-pc-windows-msvc output, using a temporary copy of the checkout's std library.

Starting points:

• compiler invocation and assertion
• executor restart fixture
• native crash diagnostic helper

Acceptance:

• Preserve the failed compiler/PDB, source/std inputs and a native stack trace or dump. The current fixture temp directory is deleted on panic, and the existing diagnostic upload is conditional on a different step failing; this run retained no build-workflow artifact.
• Separate check, IR emission, object emission and linking, and compare debug/release compiler builds to locate the overflow. Minimize the source/import graph after locating the phase.
• Determine whether recursion is unbounded or valid compilation exceeds the stack budget; fix the responsible traversal or stack provisioning with evidence. Do not hide the issue by skipping async coverage or merely weakening the assertion.
• The original fixture must compile and run on native ARM64, retaining cancellation, repeated executor restart, live-socket reuse and both close orderings.

The earlier LLVMDisposeMessage access violation is not reproduced here: the message-ownership test passes, and minimal/imported GNU/MSVC IR and object probes pass. Related: #493 and #531. This new stack overflow blocks native validation of #531.