Aspire 9.5: Debugging e2e DistributedApplicationTestingBuilder tests with Blazor Web (with wasm) projects spins up multiple browsers, times out

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

I have an Aspire project with several Blazor web apps (using both server and client wasm components).

I have a lot of e2e tests for these that run by spinning up Aspire via 'DistributedApplicationTestingBuilder' and testing against those sites with Playwright.

That has been working well for a long time and was fine recently in 9.4 with VS 2026, but seems to be broken in Aspire 9.5, it now launches multiple about:blank browsers spun up (not the playwright chromium browser, just my regular debug edge browser), then playwright starts and my tests begin to run in the chromium browser it uses (headless off for debug), but get interrupted by an 'unable to launch debug adapter' error after some timeout:

This seems to be similar if not identical to this one I raised a long while ago:

https://github.com/dotnet/aspire/issues/4607

So seem that this has regressed. Rather critical to my built/test/release pipeline unfortunately.

### Expected Behavior

These browsers shouldn't launch/try to attach when running unit tests as has previously been the case.

(Reverting back to 9.4.2 stops the problem)

### Steps To Reproduce

Create a standard blazor web project in an aspire solution with client side components.

Create a test project (xunit.v3 in my case), and use 'DistributedApplicationTestingBuilder' to spin up an apphost to test against. Use App.GetEnpoint to get the url, and spin up playwright to run a reasonably lengthy test (just do some waits).

### Exceptions (if any)

_No response_

### .NET Version info

.NET SDK:
Version: 10.0.100-rc.1.25451.107
Commit: 2db1f5ee2b
Workload version: 10.0.100-rc.1.25458.2
MSBuild version: 17.15.0-preview-25451-107+2db1f5ee2

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.100-rc.1.25451.107\

.NET workloads installed:
[android]
Installation Source: SDK 10.0.100-rc.1, VS 18.0.11018.127, VS 17.14.36518.9, VS 17.14.36518.9
Manifest Version: 36.0.0-rc.1.285/10.0.100-rc.1
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.1\microsoft.net.sdk.android\36.0.0-rc.1.285\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: SDK 10.0.100-rc.1, VS 18.0.11018.127, VS 17.14.36518.9, VS 17.14.36518.9
Manifest Version: 18.5.10727-net10-rc.1/10.0.100-rc.1
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.1\microsoft.net.sdk.ios\18.5.10727-net10-rc.1\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: SDK 10.0.100-rc.1, VS 18.0.11018.127, VS 17.14.36518.9, VS 17.14.36518.9
Manifest Version: 18.5.10727-net10-rc.1/10.0.100-rc.1
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.1\microsoft.net.sdk.maccatalyst\18.5.10727-net10-rc.1\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: SDK 10.0.100-rc.1, VS 18.0.11018.127, VS 17.14.36518.9, VS 17.14.36518.9
Manifest Version: 10.0.0-rc.1.25452.6/10.0.100-rc.1
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.1\microsoft.net.sdk.maui\10.0.0-rc.1.25452.6\WorkloadManifest.json
Install Type: Msi

[wasm-tools]
Installation Source: SDK 10.0.100-rc.1, VS 18.0.11018.127, VS 17.14.36518.9
Manifest Version: 10.0.100-rc.1.25451.107/10.0.100-rc.1
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.1\microsoft.net.workload.mono.toolchain.current\10.0.100-rc.1.25451.107\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net9]
Installation Source: SDK 10.0.100-rc.1, VS 18.0.11018.127
Manifest Version: 10.0.100-rc.1.25451.107/10.0.100-rc.1
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.1\microsoft.net.workload.mono.toolchain.net9\10.0.100-rc.1.25451.107\WorkloadManifest.json
Install Type: Msi

Configured to use workload sets when installing new manifests.

Host:
Version: 10.0.0-rc.1.25451.107
Architecture: x64
Commit: 2db1f5ee2b

.NET SDKs installed:
9.0.305 [C:\Program Files\dotnet\sdk]
10.0.100-rc.1.25451.107 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0-rc.1.25451.107 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0-rc.1.25451.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0-rc.1.25451.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

### Anything else?

Using VS 2026 insiders
Aspire 9.5

I would say these special browser instances that are launched in normal debugging to attach to blazor wasm aren't ideal in the first place, as it gives you a different debugging experience to blazor server, as well as this complexity you have to manage on testing.

My dev-loop at the moment is to set the 3 web blazor web apps to explicit start and:

1. Whenever I F5 (which is quite a bit), apply the filter on the dashboard to just my projects (as there are a lot of resources), as it doesn't remember between runs.
2. Manually start the web app I want and wait for the debug browser to appear.
3. Or, comment out explicit start on one I'm working on and remember to uncomment that.

I would be great (save a lot of cumulative time) if:

1. The dashboard retained your last filter
2. Debugging with blazor wasm apps resulted in F5 launching the aspire dashboard in a mode that VS could attach it's wasm debugging to, so you could click the links to your project and still debug web components.
3. Not need to start/open special browser windows for blazor web/wasm

Reproduce the issue with DistributedApplicationTestingBuilder, Blazor Web projects using client-side WASM components, and Playwright, comparing Aspire 9.5 with 9.4.2. Start by tracing the debugging behavior that launches the extra browsers and leads to the debug adapter timeout. Done means the end-to-end tests run without unintended browser launches or timeout interruptions.

Written by the indexing model from the issue text.