App-spawned copilot.exe processes repeatedly fast-fail on Windows (BEX64 / 0xc0000409)

### Short summary

The GitHub Copilot app spawns multiple bundled `copilot.exe` CLI processes on
Windows. These child processes repeatedly terminate with a BEX64 fatal fast-fail
(`0xc0000409`, subcode `0x7 FAST_FAIL_FATAL_APP_EXIT`), often in clusters.

### Affected version or release

- GitHub Copilot app: `1.0.26`
- Bundled Copilot CLI: `1.0.71`

### Installation context

Windows x64 desktop installation with multiple local project and chat sessions.
The observed live process tree is:

```text
github.exe 1.0.26
copilot.exe 1.0.71 --server --stdio --no-auto-update
copilot.exe ...\extension_bootstrap.mjs
```

The CLI binaries are loaded from the app-managed
`github-copilot-sdk\cli\1.0.71` installation.

### What happened?

Windows Application Error event ID 1000 recorded 89 `copilot.exe` failures over
seven days. Of those, 88 share this exact signature:

```text
Application: copilot.exe
Application version: 1.0.71.0
Faulting module: copilot.exe
Exception code: 0xc0000409
Exception data: 0x7 (FAST_FAIL_FATAL_APP_EXIT)
Fault offset: 0x0000000002224369
Event name: BEX64
WER bucket: 902d8d54b4953358c9f5f0730b398cf6
Legacy bucket: 1870665597142535414
```

The failures cluster across independent processes:

- 25 failures in one minute on July 20.
- 24 failures across two minutes on July 22.
- Two failures at the same second after an app/system restart on July 23.

Event Viewer does not preserve the parent process and command line for the
terminated PIDs, so I cannot distinguish whether every failure is the primary
`--server` process or a short-lived helper spawned by it. The current app process
tree confirms that the desktop app starts the CLI servers and that those servers
start additional `copilot.exe` helpers.

This appears related to `github/copilot-cli#4217`, which describes a Windows-only
Node/libuv shutdown race ending in the same fast-fail subcode. That report covers
CLI `1.0.73` and `1.0.74`; the app currently bundles `1.0.71`, which shows the
same fixed-signature failure at high frequency.

### Steps to reproduce

The exact trigger is not yet deterministic:

1. Run GitHub Copilot app `1.0.26` on Windows.
2. Open and use multiple local agent sessions.
3. Allow sessions and their CLI/helper processes to start and stop normally.
4. Inspect Event Viewer under **Windows Logs > Application** for Application
Error event ID 1000 and Windows Error Reporting event ID 1001.
5. Observe clustered `copilot.exe` BEX64 failures with the signature above.

### Expected behavior

CLI server and helper processes started by the desktop app should exit cleanly.
The app should not repeatedly launch or restart a bundled CLI build that
fast-fails during teardown. If a child exits abnormally, the app should surface
an actionable diagnostic rather than leaving repeated WER crash records.

### Additional context

```text
OS: Windows 11 Enterprise 25H2, build 26200.8893, x64
GitHub Copilot app: 1.0.26
Copilot CLI: 1.0.71
```

I have not live-debugged the `1.0.71` process, so I cannot independently confirm
the `uv_async_send` stack reported in `github/copilot-cli#4217`. The fixed
offset, BEX64 classification, and fast-fail subcode are consistent with that
failure class.

WER application dumps are available for private transfer if maintainers need to
symbolize the `1.0.71` fault offset.

Start with the Windows Application Error event ID 1000 and Windows Error Reporting event ID 1001 details for the bundled Copilot CLI 1.0.71, then compare the failure signature with github/copilot-cli#4217. Use the available WER application dumps to investigate the fixed fault offset and determine whether the affected process is the server or a helper; done means the app's CLI processes exit cleanly without repeated matching BEX64 records.

Written by the indexing model from the issue text.