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.

先查看随附的 Copilot CLI 1.0.71 的 Windows Application Error 事件 ID 1000 和 Windows Error Reporting 事件 ID 1001 的详细信息，然后将故障特征与 github/copilot-cli#4217 进行比较。使用可用的 WER 应用程序转储来调查固定的故障偏移量，并确定受影响的进程是服务器还是辅助进程；完成的标准是应用程序的 CLI 进程能够正常退出，且不再反复出现匹配的 BEX64 记录。

由索引模型根据 Issue 内容生成。