Recover native ARM64 crash evidence when LLDB stalls on the imported fixture

## Observed native CI behavior

In [PR #574's native ARM64 diagnostic job](https://github.com/wavefnd/Wave/actions/runs/34583004824/job/103210688545) at `ed149e7553c06efc30b5167920cc301563d6afb3`:

- `minimal.wave` passes frontend checking; GNU and MSVC IR emission both exit `0xC0000005`.
- LLDB captures a stack for both minimal inputs.
- `tests/cases/windows/arm64/test1.wave` also passes checking and exits `0xC0000005` promptly outside LLDB.
- For that imported fixture, **both** GNU and MSVC debugger probes stop logging at `(lldb) run` and time out after **90 seconds**, producing no stack or register report for that input.

The job artifact `windows-arm64-codegen-diagnostics` contains `test1-gnu-ir-debugger.log` and `test1-msvc-ir-debugger.log` with this exact timeout. LLVM and LLDB are 21.1.8 on `windows-11-vs2026-arm`, with native ARM64 Python 3.11 and compiler symbols.

Source: [bounded debugger invocation](https://github.com/wavefnd/Wave/blob/ed149e7553c06efc30b5167920cc301563d6afb3/tools/diagnose_windows_arm64.py#L89).

## Investigation and acceptance

- [ ] Reproduce the debugger-only stall using the saved native compiler and imported input; distinguish launch, exception handling, symbol loading, and pipe/process-supervision waits.
- [ ] Collect bounded fallback evidence when LLDB cannot complete, such as a dump or another supported native debugger path.
- [ ] Preserve the original compiler failure and clearly distinguish debugger failure from compiler timeout.
- [ ] Keep time limits and descendant cleanup; do not merely remove the timeout or skip the imported input.
- [ ] Demonstrate useful evidence for both minimal and imported inputs on native ARM64.

The known compiler crash stays in #493. This issue tracks reliability of the diagnostic collector; the successful minimal backtrace must not be described as missing.

Start at tools/diagnose_windows_arm64.py around the bounded debugger invocation, then replay the saved native compiler and imported tests/cases/windows/arm64/test1.wave input using the linked CI artifact logs. Compare minimal.wave and test1.wave results, identifying whether the stall occurs during launch, exception handling, symbol loading, or process supervision. Done means bounded fallback evidence, preserved compiler failures, descendant cleanup, and useful evidence for both inputs.

Written by the indexing model from the issue text.