Blazor debugging captures unrelated debug sessions and terminates them together

## Summary

While a Blazor WebAssembly debugging session is active, the C# extension captures unrelated debug sessions that start afterward. Closing the Blazor browser then terminates those unrelated sessions. The reverse also happens: stopping an unrelated session started after Blazor attachment terminates the Blazor browser and managed debugger.

**Reproduced with the actual Marketplace C# extension, a real Edge browser rendering a Blazor WebAssembly app, `monovsdbg_wasm`, and independent Node debug processes.** No provider mocks, replacement debug adapters, or Aspire extension code were used. Both directions reproduced in two complete runs.

Sessions started **before** Blazor attachment are unaffected: a preexisting Node session remained active and its process heartbeat continued advancing after both teardown scenarios.

## Environment data

- Windows ARM64, OS build 10.0.26200.
- VS Code 1.137.0, commit `645f29cc3176500b4b5762ba887cf2a7f0ffdf2c`.
- `ms-dotnettools.csharp` 2.148.23, Marketplace win32-arm64 VSIX.
- C# Dev Kit 3.20.207; .NET Install Tool 3.1.0.
- .NET SDK 10.0.112; standalone Blazor WebAssembly template targeting `net10.0`, WebAssembly/DevServer packages 10.0.12.
- Edge 152.0.4191.62, headless.
- Node 25.9.0 for the independent debuggees; extension-host Node 24.18.1.
- Execution used an isolated VS Code Extension Development Host with dedicated user-data and extension directories. Normal installed extensions/settings were not modified.

Inspected source: tag `v2.148.23-prerelease`, commit [`2f5806a9f39575bfaf4ca16445f420440a43e050`](https://github.com/dotnet/vscode-csharp/tree/2f5806a9f39575bfaf4ca16445f420440a43e050).

## Steps to reproduce

The following sequence was executed through the VS Code debug API in the isolated Extension Development Host. All root sessions were launched independently: **no compound launch, parent-session argument, or explicit cascade setting was assigned to either Node configuration.**

1. Create and run a standalone .NET 10 Blazor WebAssembly app (`dotnet new blazorwasm`). Open the client folder in VS Code and wait for C#/Razor initialization.
2. Start an independent Node debug session named `preexisting`. Its program writes a heartbeat every 200 ms, allowing survival to be checked independently of VS Code's session list.
3. Start Blazor debugging against the already-running app using the configuration below. Wait for the actual browser/page sessions and `monovsdbg_wasm`, and for the page to render.
4. Start another independent Node debug session named `unrelated-after`, running the same heartbeat program.
5. **Scenario A:** close only the Blazor browser. In the executed reproduction, this was a CDP `Browser.close` request to the browser's real debugger endpoint, not a VS Code stop-all operation.
6. Observe that `unrelated-after` also terminates, although it has no relationship to the Blazor app. `preexisting` remains active and its heartbeat continues.
7. Repeat steps 2–4 with fresh sessions. **Scenario B:** call `vscode.debug.stopDebugging(unrelatedAfterSession)` for only the later Node root session.
8. Observe that the Blazor browser/page and `monovsdbg_wasm` also terminate. Again, `preexisting` survives and continues executing.

Blazor configuration used by the reproduction (paths and URL below are placeholders):

```javascript
{
type: "blazorwasm",
request: "attach",
name: "blazor-browser",
projectPath: "",
cwd: "",
url: "",
browser: "edge",
webRoot: "",
browserConfig: {
userDataDir: "",
runtimeArgs: [
"--headless=new",
"--no-first-run",
"--no-default-browser-check"
],
trace: true
}
}
```

The independent sessions use ordinary `pwa-node` configurations with `request: "launch"`, distinct names, `program` pointing at a long-running Node script, and `console: "internalConsole"`. They are launched with `vscode.debug.startDebugging(undefined, configuration)` and no third argument. A minimal long-running program is:

```javascript
setInterval(() => console.log(`heartbeat ${Date.now()}`), 200);
```

The executed driver additionally writes heartbeats to separate files and asserts that the preexisting process keeps executing after teardown. Browser rendering was confirmed through the page session's DAP `evaluate` request: `document.body.innerText.includes("Hello, world!")` returned `true` before starting the unrelated session.

## Expected behavior

Only debug sessions owned by the same Blazor launch should participate in its cascade termination. An independent session must remain independent regardless of whether it starts before or after Blazor attachment.

- Closing the Blazor browser should not stop an unrelated Node session.
- Stopping that Node session should not stop Blazor debugging.

## Actual behavior

| Trigger | Blazor browser/managed sessions | Unrelated session started after attach | Preexisting session |
| --- | --- | --- | --- |
| CDP `Browser.close` | Terminated | **Unexpectedly terminated** | Survived; heartbeat advanced |
| Stop only `unrelated-after` | **Unexpectedly terminated** | Terminated as requested | Survived; heartbeat advanced |

## Logs / runtime evidence

Condensed from the successful `onDidStartDebugSession` / `onDidTerminateDebugSession` event trace on September 11, 2026 (UTC). The driver observes events; it does not stop any additional sessions until after recording each scenario result.

```text
15:35:40.153 started preexisting (pwa-node)
15:35:40.958 requested Blazor attach
15:35:44.969 started Wasm Managed Debugger (monovsdbg_wasm)
15:35:48.852 started Blazor browser (pwa-msedge)
15:35:56.335 Blazor DOM rendering confirmed
15:35:56.846 started unrelated-after (pwa-node)
15:35:57.514 requested CDP Browser.close
15:35:57.885 browser page terminated
15:35:58.836 managed debugger terminated
15:35:58.863 browser root terminated
15:36:02.642 unrelated-after root terminated
15:36:03.007 result: preexisting survived; heartbeat advanced

15:36:06.129 requested fresh Blazor attach (after fresh preexisting Node start)
15:36:08.897 started Wasm Managed Debugger (monovsdbg_wasm)
15:36:13.947 started Blazor browser (pwa-msedge)
15:36:22.845 Blazor DOM rendering confirmed
15:36:24.028 started unrelated-after (pwa-node)
15:36:24.900 requested stopDebugging(unrelatedAfterSession) only
15:36:25.720 unrelated-after root terminated
15:36:25.772 browser page terminated
15:36:26.594 managed debugger terminated
15:36:26.621 browser root terminated
15:36:26.835 result: preexisting survived; heartbeat advanced
```

An earlier complete run reproduced both directions at 15:28 UTC as well. Raw C# diagnostics contain machine-local paths and are omitted here; the structured trace above contains the directly observed lifecycle evidence.

## Code gap

The observed timing matches the static tracking in `BlazorDebugConfigurationProvider`:

1. [Lines 73–98](https://github.com/dotnet/vscode-csharp/blob/2f5806a9f39575bfaf4ca16445f420440a43e050/src/razor/src/blazorDebug/blazorDebugConfigurationProvider.ts#L73-L98): one static tracking flag/set/map; `onDidStartDebugSession` captures **every** session while tracking is enabled, with no ownership or launch-group filter.
2. [Lines 101–116](https://github.com/dotnet/vscode-csharp/blob/2f5806a9f39575bfaf4ca16445f420440a43e050/src/razor/src/blazorDebug/blazorDebugConfigurationProvider.ts#L101-L116): when any captured session terminates, the handler calls `stopDebugging` on every captured peer.
3. [Lines 136–142](https://github.com/dotnet/vscode-csharp/blob/2f5806a9f39575bfaf4ca16445f420440a43e050/src/razor/src/blazorDebug/blazorDebugConfigurationProvider.ts#L136-L142): `resolveDebugConfiguration` clears the collections and enables tracking. Tracking remains enabled until a captured session terminates, rather than being scoped to sessions owned by this launch.
4. [Lines 795–800](https://github.com/dotnet/vscode-csharp/blob/2f5806a9f39575bfaf4ca16445f420440a43e050/src/razor/src/blazorDebug/blazorDebugConfigurationProvider.ts#L795-L800): `tryToUseVSDbgForMono` enables the same global state.

Please scope cascade tracking to the sessions owned by each Blazor launch, with regression coverage for unrelated sessions started during an active Blazor session in both termination directions.

## Additional context

This was identified while reviewing the new managed-browser integration in microsoft/aspire#20001, which calls the high-level `blazorwasm` attach provider. The reproduction deliberately omits Aspire to isolate the upstream behavior.

This is distinct from #7864 (processes left running/port conflicts after closing debugging) and #7386 (an older C# Dev Kit/Aspire shutdown issue).

The successful reproduction used a headless browser and VS Code API automation, not UI-click automation. It confirms real browser rendering and managed-debugger lifetime, but does not assert a managed C# breakpoint or cover two simultaneous Blazor launch groups. All reproduction-owned processes were cleaned up afterward.

Read src/razor/src/blazorDebug/blazorDebugConfigurationProvider.ts, especially lines 73–142 and 795–800, and trace the debug-session start and termination handlers. Add regression coverage for unrelated Node sessions started during Blazor debugging in both teardown directions; done means those sessions remain independent while Blazor-owned sessions still cascade.

Written by the indexing model from the issue text.