VS Code: Blazor WebAssembly debugging intermittently fails to attach on Windows

### Is there an existing issue for this?

- [x] I have searched the existing issues.

### Describe the bug

With #20001 in place, debugging a standalone Blazor WebAssembly application through Aspire intermittently fails on Windows before the debugger discovers the application page.

The `monovsdbg_wasm` managed session terminates during initial browser attachment. The browser debugger then retries unsuccessfully, without creating a page session or reaching managed breakpoints.

The same failure occurred in the original Windows CI run and a fresh Windows x64 rerun of the **same commit**, `9b0f7891cd1e2bb89e5cdbc926cca9aa17e2bbd7`. An intervening retry passed.

In the fresh failing run, subsequent hosted scenarios were blocked by this modal:

> It looks like a browser is already running from an old debug session. Please close it before trying to debug, otherwise VS Code may not be able to connect to it.

Those later failures appear to be recovery failures following the initial attachment failure, rather than independent reproductions of it.

### Expected Behavior

Starting browser debugging should attach both the browser and managed debugger and allow C# breakpoints to be hit.

If attachment fails, the browser and debugger sessions should be cleaned up so subsequent launches are not blocked by an old-session prompt.

### Steps To Reproduce

1. Use the commit above on Windows x64 with the matching Aspire CLI/packages, VS Code **1.130.0**, C# extension **2.148.23**, and .NET 10 fixtures.
2. Run the existing `browser-debugger` extension E2E shard using a fresh isolated VS Code profile. The [fixture generator](https://github.com/microsoft/aspire/blob/9b0f7891cd1e2bb89e5cdbc926cca9aa17e2bbd7/extension/scripts/run-e2e.js) creates the standalone Blazor client behind a gateway at `/standalone/`.
3. The [standalone scenario](https://github.com/microsoft/aspire/blob/9b0f7891cd1e2bb89e5cdbc926cca9aa17e2bbd7/extension/src/test-e2e/browserDebugger.e2e.test.ts) starts the AppHost, invokes `debug-in-browser` for `standalone`, and attempts to hit a managed breakpoint in `Counter.razor`.

The failure is intermittent.

### Exceptions (if any)

Representative errors:

```text
Timed out after 294732ms waiting for pwa-msedge child session
Browser connection failed, will retry: Unable to attach to browser
System.Net.Sockets.SocketException (10061):
No connection could be made because the target machine actively refused it.
at Microsoft.WebAssembly.Diagnostics.CorDebugProxy.RunForDevTools(...)
```

The fresh failure's chronology is important:

| UTC | Event |
|---|---|
| 16:03:52.118 | Browser launch requested |
| 16:03:57.384 | `Target.attachToBrowserTarget` sent |
| 16:04:00.927 | Managed session termination observed |
| 16:04:00.973–00.974 | Browser attachment event arrives, then CDP connection closes |
| 16:04:08 | First bridge connection-refused error |

No application page is discovered or navigated to. The connection refusals and eventual timeout occur **after** managed termination.

### Aspire doctor output

Not collected; reproduction evidence comes from the Windows CI jobs below.

### Anything else?

| Execution | Result |
|---|---|
| [Original Windows failure](https://github.com/microsoft/aspire/actions/runs/34314035384/job/102348757446) | Standalone attachment fails |
| [Intervening Windows retry](https://github.com/microsoft/aspire/actions/runs/34314035384/job/102351645031) | All eight scenarios pass |
| [Fresh Windows x64 reproduction](https://github.com/microsoft/aspire/actions/runs/34314035384/job/104048374893) | Same standalone failure; subsequent hosted launches blocked |

The fresh run's `extension-e2e-diagnostics-win-x64-browser-debugger-attempt3` artifact contains the C# and bridge logs, js-debug trace, failure diagnostics, and modal screenshot.

**Root cause remains unconfirmed.** The logs do not identify what initiated managed termination. Managed DAP lifecycle traffic and native bridge/debugger diagnostics are needed to distinguish an internal failure from externally requested teardown.

There is currently no evidence establishing dotnet/vscode-csharp#9750 as the trigger. Related Aspire tracking: #17797.

Start by running the existing browser-debugger extension E2E shard on Windows x64 with a fresh isolated VS Code profile, using extension/scripts/run-e2e.js and extension/src/test-e2e/browserDebugger.e2e.test.ts. Review the C# and bridge logs, js-debug trace, and failure diagnostics to determine what initiates managed session termination. Done means browser and managed debugging attach reliably, hit the Counter.razor breakpoint, and clean up sessions after failure.

Written by the indexing model from the issue text.