copilot.exe fatal-aborts under load (BEX64 / 0xc0000409) — reproducible across 1.0.57 and 1.0.60 on Windows ARM64

## Summary

The interactive CLI process (`copilot.exe`) hard-aborts with a Windows fatal-app-exit instead of shutting down gracefully. It fires most reliably when several sessions start at once (Windows Terminal tab restore) under memory pressure, but it has also fired mid-session. The terminal has to be closed and reopened each time.

Over the last 5 days Windows Error Reporting logged **45 crashes** of `copilot.exe` on this machine, across two CLI versions. This is reproducible and ongoing, not a one-off.

Likely the same root cause as #3250 (BYOK + parallel subagents) and #2335 (multiple hard crashes on Windows 26200). Same exception path and OS build. Filing separately because the trigger here is general load / simultaneous startup with the stock provider, and the multi-version data may help.

## Environment

- Copilot CLI version: `1.0.60-0` (also reproduced on `1.0.57.0`)
- Bundled Node: `v24.16.0`
- OS: Windows 11 Pro, build `10.0.26200`
- Arch: **ARM64**
- Plan: Enterprise
- Host: Windows Terminal, pwsh
- RAM: 32 GB. Crashes correlate with free RAM dropping to roughly 2 GB.

## Crash signature (Windows Application event log, Event ID 1000 / WER 1001)

```text
Faulting application name: copilot.exe, version: 1.0.60.0
Faulting module name: copilot.exe, version: 1.0.60.0
Exception code: 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN / __fastfail)
Exception Data (P9): 0000000000000007 (FAST_FAIL_FATAL_APP_EXIT)
Event Name: BEX64
IsFatal: 1
Fault offset: 0x0000000001cdd3dc
```

`0xc0000409` with subcode `7` is `__fastfail(FAST_FAIL_FATAL_APP_EXIT)`, the path the bundled Node/V8 runtime takes when it calls `abort()` on a fatal error (uncaught fatal, V8 fatal, or JavaScript heap out of memory). The faulting module is `copilot.exe` itself because the CLI ships as a Node single-executable, so V8 runs inside the binary. This is a deliberate runtime self-termination, not native memory corruption.

## Two distinct WER fault buckets, one per version

| Version | WER bucket | Crashes (5 days) |
|----------|-----------------------|------------------|
| 1.0.57.0 | `2212194956551539350` | 28 |
| 1.0.60.0 | `1899762302600568482` | 17 |

The 1.0.57 to 1.0.60 update changed the bucket but did not fix the abort path.

## Crash clustering (auto-restart loop)

Crashes arrive in tight bursts, consistent with crash, auto-restart, crash again under the same memory pressure. Examples from one morning:

```text
09:30:29, 09:30:36, 09:30:49, 09:30:53, 09:30:58, 09:30:58 (6 crashes in ~30s)
09:08:10 x4 (four sessions aborting in the same second)
```

## Steps to reproduce (best-effort, load-dependent)

1. On Windows ARM64, have several saved interactive sessions, each with a few MCP servers configured (mix of stdio node/npx and remote HTTP).
2. Launch many at once, for example restore 6+ Windows Terminal tabs simultaneously, each running `copilot --resume`.
3. While the MCP servers all cold-start and free RAM falls toward ~2 GB, one or more `copilot.exe` processes fatal-abort with the signature above.

Not a guaranteed single-step repro, but the correlation with simultaneous startup and low free memory is consistent across dozens of occurrences.

## What I ruled out

- **Not a clean shutdown.** The structured session logs that end with `[shutdown] Shutdown complete` are headless prompt-mode runs, not the interactive TUI. The interactive process leaves no graceful log line, only the WER record.
- **Not MCP-config-specific.** Reproduces after trimming to 7 global MCP servers and with an empty project-level config.
- **Not a Windows Terminal hang.** This is `copilot.exe` faulting, captured by WER with a full dump reference.

## Expected behavior

The runtime should not hard-abort under memory pressure or concurrent startup. At minimum the fatal reason should be recoverable from a log, not only from Windows Error Reporting.

## Asks

1. Surface the actual fatal reason before aborting. Today the only artifact is the WER record. If this is heap OOM, writing the V8 fatal / heap-limit context to the session log (not just terminal stderr, which dies with the process) would confirm it.
2. If it is heap OOM, consider a higher default old-space limit for the bundled runtime, or backpressure when many MCP servers initialize concurrently.
3. Guard against the crash-restart loop: if a session aborts on startup, avoid immediately relaunching into the same memory-pressure condition.

## Attachments available on request

WER dump (`WER.*.dmp`) and the full per-timestamp crash timeline.