fix: make CI case results reliable and restore ARM64 validation

[LunaStev]

Case execution currently lets a compiler error satisfy an expected nonzero program exit, while the all-target precheck stops at the first error and prevents native results from being collected. Windows ARM64 also fails before meaningful runtime validation: implicit-target Cargo builds misclassify SDK import libraries, and debug module resolution exhausts a small process stack.

This PR contains one commit per issue:

• Reject compiler failures in cases that expect a nonzero program exit #577: build into a fresh directory, require successful executable production, then supervise the program separately. Compiler/linker/launch failures cannot satisfy its exit contract; stdin, target selection and process-tree cleanup are retained.

• Collect all case precheck failures without suppressing native execution and reports #610: collect every manifest source-check result and preserve its diagnostics. Native cases remain eligible after a precheck failure only when compiler/std prerequisites succeeded. The workflow remains failing when either phase fails.

• Restore Windows ARM64 case builds when static CRT linking cannot locate psapi #608: use the explicit ARM64 Cargo target already used by the working build/release paths, keeping target CRT flags off host build scripts. llvm-sys 211 uses its own cfg!(target_feature = "crt-static") to classify system libraries; the implicit-target build changes this to static bundling of SDK imports such as psapi. Keep the required static CRT allocator configuration and stage the verified compiler for the existing case runner.

• Fix native Windows ARM64 compiler stack overflow on the executor restart fixture #609: replace recursive expression reconstruction in module resolution with an in-place worklist, preserving traversal and diagnostic order. The original executor fixture now passes check/IR/ARM64 MSVC object emission under a 1 MiB process stack; retain compiler/PDB/fixture/std/diagnostics on native runtime failures.

• Repair the stale process helper import in the Linux amd64 case suite #607: remove the unused import of the retired _proc_dup_child_fd helper from the Linux amd64 process case; preserve the test workload.

Validation:

• Rust workspace/all-target tests: 196 passed; fmt, Clippy with denied warnings, rustdoc with denied warnings, and std policy passed.
• Python discovery: 63 tests, 62 passed and one Windows-only test skipped on Linux.
• CI-matching Rust 1.89: all 20 frontend/runtime tests passed, including the 1 MiB stack regression.
• Wave corpus: 277 passed; std examples: 26 passed.
• Source precheck: all 605 sources passed after removing the stale import.
• The repaired linux/amd64/test13.wave executes successfully locally. Full-suite testing on this machine is affected by the existing server-port isolation issue Require the server case to validate its own generated process #580 (another service uses port 8080).
• Native Windows ARM64 build job: passed before the isolated Linux import correction, including Clippy, LLVM allocator ownership, MSVC companion publication and actual executor restart execution (sockets_survive_executor_restart_and_release_their_completion_port).
• Native ARM64 cases job: before the isolated Linux import correction, compiler build and architecture verification passed, confirming that the psapi failure is resolved; all 135 native cases passed with zero failures/timeouts and the report was uploaded.
• CI evidence for Collect all case precheck failures without suppressing native execution and reports #610: the preceding head ran all 148 native Linux cases despite the precheck failure and uploaded both reports. Its only failure was the stale import now repaired by Repair the stale process helper import in the Linux amd64 case suite #607; the new head reruns this required job.

Fixes #577
Fixes #610
Fixes #608
Fixes #609

Fixes #607

CI follow-up: the macOS ARM64 Python process-tree timeout test once returned a failure classification instead of the expected timeout, but the assertion discarded the captured subprocess output. The assertion now includes that output and the classification detail without changing timeout or pass/fail behavior. The macOS ARM64 job, including Python tooling and Rust validation, passes on rerun; the original intermittent failure's cause has not been identified, so this is diagnostic hardening rather than a claimed fix for a proven subprocess cause.