Blazor WebAssembly debugger: `decode_ptr_id` assertion at startup, BPs solid-red but never hit — VS2026 18.6.0 + dn10 SDK 10.0.300 (similar to #121738 which is reportedly fixed)

### Description

VS2026 18.6.0 paired with dn10 SDK 10.0.300 produces an unusable debug experience for a large Standalone Blazor WebAssembly app. The symptoms closely match those reported in #121738, but that issue's final comment indicates a fix shipped in VS 18.3 Insiders 2 — I'm on 18.6.0 (later) and reproducing, so this looks like either a regression or a closely related-but-distinct issue.

A vanilla `dotnet new blazorwasm -f net10.0` project on the same machine debugs perfectly. So VS + SDK + browser are functional in isolation; something about my (large, ABP 10.3-based, ~100 project references) solution amplifies the problem.

### Reproduction Steps

I do not currently have a minimal repro — the issue appears to be sensitive to solution scale (~100 project refs vs vanilla's ~5). Steps I take when reproducing locally:

1. Open the solution in VS2026 18.6.0
2. F5 multi-startup (tenant API + host API + tenant WASM client + host WASM client)
3. Once the tenant WASM app loads in the browser, set a breakpoint in any reachable C# code (e.g. a Razor page's `OnInitializedAsync`, a button click handler, an ABP module's `ConfigureServices`)
4. Trigger the path

I'm willing to work toward a minimal repro if a maintainer can confirm interest — the scale-dependence makes it non-trivial.

### Expected behavior

- Breakpoints bind (solid red) and **hit** when the underlying code executes
- No `[MONO] * Assertion` in the browser console when setting breakpoints
- No spurious JS-side breaks at startup
- Stopping the debug session completes promptly and releases all file handles

### Actual behavior

Three persistent symptoms:

1. **"Play-button plague"** — many JS-side breakpoints fire at WASM startup; user has to click play repeatedly before VS hooks up.
2. **Managed breakpoints never hit.** VS shows them solid-red (PDB binding succeeds at IDE level) but they're inert at runtime. Stack trace captured in browser console when setting a BP:

```
[MONO] * Assertion at /__w/1/s/src/runtime/src/mono/mono/component/debugger-agent.c:2043, condition `' not met

at Mc (logging.ts:125:60)
at dotnet.native.wasm.wasm_trace_logger
at dotnet.native.wasm.eglib_log_adapter
at dotnet.native.wasm.monoeg_g_logv_nofree
at dotnet.native.wasm.monoeg_assertion_message
at dotnet.native.wasm.mono_assertion_message
at dotnet.native.wasm.mono_assertion_message_disabled
at dotnet.native.wasm.decode_ptr_id (debugger-agent.c:2043)
at dotnet.native.wasm.mono_process_dbg_packet
at dotnet.native.wasm.mono_wasm_send_dbg_command
at ccall (dotnet.native.js:6715)
at mono_wasm_send_dbg_command (debug.ts:94)
at (anonymous) (eval.cdp:1)
at (anonymous) (debug.ts:33)
at configureEmscriptenStartup (startup.ts:340)
```

Path: `startup.ts:340` → `onRuntimeInitialized` → `mono_wasm_runtime_ready` (which executes `debugger;` when `globalThis.dotnetDebugger` is set) → VS catches the break → CDP `eval` calls `mono_wasm_send_dbg_command` with a `ptr_id` that fails the `g_assert (id > 0 && GINT_TO_UINT(id) <= ids[type]->len)` check in `decode_ptr_id`. The agent's state appears corrupted from boot; subsequent BPs are silently inert.

Sometimes accompanied by `program exited (with status: 1), but keepRuntimeAlive() is set` shortly after.

3. **Stop-debug hangs**, eventually requiring "force stop"; leaves a persistent file lock on project-ref DLLs held by `devenv.exe` (e.g. `MyApp.Components.Shared.dll`), preventing the next build.

### Regression?

Likely. Closest matching issue #121738 was reportedly fixed in VS 18.3 Insiders 2, but I'm reproducing on 18.6.0. Behavioural notes:

- I cannot test prior VS2026 versions easily but did upgrade to 18.6.0 mid-investigation with no change in symptoms.
- The app debugged correctly under VS 2022 / .NET 8 prior to our dn8 → dn10 upgrade. So the regression entered with the dn10 SDK + VS2026 combination.
- A colleague on the same codebase using **Rider** does not see any of these symptoms — different debug protocol adapter, so the problem looks specific to the VS WASM debug adapter.

### Known Workarounds

**None that I have found that retain working managed debug.** Things tried and confirmed not to fix it:

- **Disable "Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE)"** (the documented workaround from #121738) — already off in my VS and was off long before symptoms started.
- Toggle `WasmBuildNative`, `OverrideHtmlAssetPlaceholders`, ``, `WasmFingerprintAssets`, `BlazorFingerprintBlazorJs`, `BlazorWebAssemblyLoadAllGlobalizationData` individually.
- Disable "Just My Code".
- Disable / comment out our custom service worker registration (the dev SW is a passthrough with no `fetch` handler, so this was expected to be inert; confirmed).
- "Nuclear" cache reset: close VS, kill all helper processes, `dotnet build-server shutdown`, delete `.vs/`, all `bin/` and `obj/` solution-wide, VS `ComponentModelCache` at `%LOCALAPPDATA%\Microsoft\VisualStudio\18.0_*\ComponentModelCache`, `dotnet restore`, browser SW unregister + clear site data. No effect.
- VS upgrade from earlier to 18.6.0.

Removing `inspectUri` from `launchSettings.json` suppresses the symptoms but only by disabling the managed debug channel entirely — i.e. no debug at all, not a real workaround.

The only thing that works in practice: switch to Rider.

### Configuration

- **VS:** Visual Studio 2026 18.6.0
- **SDK:** 10.0.300 (runtime 10.0.8)
- **App:** Standalone Blazor WebAssembly, ABP Framework 10.3, ~100 project references
- **OS:** Windows 11
- **Browser:** Chrome (latest stable). Symptom reproduces in Edge too.

### Other information

**Vanilla comparator on the same machine:** `dotnet new blazorwasm -f net10.0` in `C:\Temp\vanilla-dn10-wasm`, opened in VS, F5 — BPs bind AND hit, no play-button plague, no `decode_ptr_id` assertion, no DLL locks. So this is specifically an interaction between something in the large solution and the VS2026 WASM debug adapter.

**Property diff** between my csproj and the vanilla template (just the properties I set that vanilla doesn't): `BlazorWebAssemblyLoadAllGlobalizationData=true`, `ServiceWorkerAssetsManifest`, `WasmFingerprintAssets=false`, `BlazorFingerprintBlazorJs=false`, `WasmBuildNative=true`, `EmitCompilerGeneratedFiles=true`. Toggling each individually did not move the needle.

**Hypothesis** (best guess from outside): the dn10 WASM debug agent's `ids[type]` array isn't fully populated at the moment VS issues its startup debug commands via CDP eval, leading to out-of-bounds `ptr_id` lookups in `decode_ptr_id`. Large solutions may load assemblies more slowly relative to VS's attach pacing, exposing the race. The assertion silently corrupts agent state, and all subsequent BP-set commands then fail to wire through to the runtime.

Happy to provide more diagnostic info, build logs, launchSettings, or work toward a minimal repro if useful — please flag what would be most helpful.