[Validation] Blazor Hybrid teardown while JavaScript calls are in flight

**Scenario contact:** @javiercn

## Scenario

**This scenario validates that a fix works.** A native app hosting Blazor is closed, backgrounded and navigated around far more abruptly than a web page, and its components are often in the middle of talking to JavaScript when that happens. Disposing an `IJSObjectReference` after the WebView had gone threw `JSDisconnectedException`, which showed up as hangs on teardown and alarming errors in the debug output. Navigation and disposal now mark the JS runtime disconnected before components are disposed, and that exception is caught and discarded.

This validates that a Hybrid app tears down cleanly.

## Minimum build

.NET 11 Preview 7 or later.

## Configurations to cover

* Blazor Web App
* [ ] Static SSR
* [ ] Interactive Server
* [ ] Interactive WebAssembly
* [ ] Interactive Auto
* [ ] Standalone WebAssembly
* [x] Hybrid (MAUI)

## Also exercise

* [ ] Published output
* [ ] An existing .NET 10 app upgraded to .NET 11
* [ ] Trimming or ahead-of-time compilation
* [ ] More than one server instance, or a proxy in front
* [ ] Hot Reload
* [ ] An IDE as well as the command line
* [ ] Container

## Setup

You need the workloads for building a native app for at least one platform, and a device or emulator. Covering more than one platform is worthwhile, since the embedded browser differs between them.

## What to build

A native app hosting Blazor, with pages that are busy in ways that make teardown awkward. Include a page that keeps a JavaScript module loaded and calls into it repeatedly, one that starts a slow JavaScript call and does not wait for it, one with a timer that keeps firing, and one that has registered .NET methods for JavaScript to call back into. Give the components proper cleanup so you can tell whether it runs. Add a native page alongside the Blazor content so you can move between the two kinds of screen, and log to the debug output when each component is cleaned up.

## Things to try

* Navigating away from each busy page while it is mid-flight.
* Moving from a Blazor screen to a native screen and back, repeatedly.
* Closing the app while a page is in the middle of a JavaScript call.
* Backgrounding the app and returning to it, and backgrounding it and then closing it.
* Using the operating system's back gesture or button rather than in-app navigation.
* Rotating the device while a page is busy.
* Repeating the cycle many times in one session and watching memory.
* Watching the debug output throughout for exceptions and warnings.

## Expected behavior

Teardown completes promptly however busy the page was, and calls that were already in flight go quietly.

### Must hold

* Leaving each busy page runs its cleanup and does not hang.
* Closing the app while a JavaScript call is in flight terminates promptly rather than waiting on work that will never finish.
* No exception from calls that were in flight appears in the debug output. In particular, disposing a JavaScript object reference after the connection is gone must not surface a `JSDisconnectedException`.
* Repeated moves between Blazor and native screens leave memory stable across the session.
* Returning from the background finds the app in a working state.

### Expected differences between configurations

* The embedded browser differs between platforms, so cover more than one if you can. A teardown that is clean on one platform and not on another is a finding.

## Documentation to use

* [ASP.NET Core Blazor Hybrid](https://learn.microsoft.com/aspnet/core/blazor/hybrid/?view=aspnetcore-11.0)
* [Component disposal](https://learn.microsoft.com/aspnet/core/blazor/components/component-disposal?view=aspnetcore-11.0)

## What to report

Report results using the format described in the [validation testing manual](https://github.com/dotnet/aspnetcore/issues/68479). Include link to a repository with the test app.