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.

Commencez par les détails de l’événement Windows Application Error avec l’ID d’événement 1000 et de l’événement Windows Error Reporting avec l’ID d’événement 1001 pour la Copilot CLI 1.0.71 fournie, puis comparez la signature de l’échec avec github/copilot-cli#4217. Utilisez les vidages d’application WER disponibles pour examiner l’offset de faute fixe et déterminer si le processus concerné est le serveur ou un processus auxiliaire ; le travail est terminé lorsque les processus CLI de l’application se terminent proprement sans enregistrements BEX64 correspondants répétés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.