[Validation] Navigating between pages that use different render modes

**Scenario contact:** @javiercn

## Scenario

Blazor writes bookkeeping into the page as HTML comments: WebAssembly options, persisted component state, JavaScript initializers. In .NET 10 those comments were pulled into Blazor's logical tree during the first render, then removed from the DOM during component discovery, leaving the tree pointing at nodes that no longer existed. The next enhanced navigation across a render-mode boundary hit one of those dangling references and threw `Cannot read properties of null (reading 'insertBefore')`: the address bar changed, no new page appeared, and only a full reload or `forceLoad: true` recovered.

This is a .NET 10 regression. The `` comment arrived in .NET 10 with WebAssembly options discovery, and nothing filtered it out of the tree. .NET 11 skips metadata comments when the logical tree is built. Two separate customer reports drove the fix, and this scenario reproduces both: navigating from a WebAssembly page to an Interactive Server page, and navigating away from a page that sets no ``.

## Minimum build

.NET 11 Preview 7 or later.

## Configurations to cover

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

This is **one app containing all three modes**, not three runs. The ticks say which page render modes the app needs, because the bug only appears when navigating from one mode to another.

The app must be WebAssembly-capable, since that is what emits the `Blazor-WebAssembly` comment the regression was about. Create it with `-int Auto` or `-int WebAssembly` and then set the mode per page. Interactive Auto is left unticked as a page mode: an Auto page is Server on the first visit and WebAssembly afterwards, so it exercises the same two paths the other pages already cover.

## Also exercise

* [x] Published output
* [x] 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

Published output is included because the `Blazor-WebAssembly` comment carries the fingerprinted resource collection, so its contents differ from a development build.

## What to build

Create the app with `dotnet new blazor -int Auto`, leaving interactivity per page rather than global. The two reported repros need a specific arrangement, so follow this table exactly:

| Route | Render mode | Project | `` |
|---|---|---|---|
| `/` | `@rendermode InteractiveWebAssembly` | `.Client` | yes |
| `/counter` | `@rendermode InteractiveWebAssembly` | `.Client` | **none** |
| `/weather` | `@rendermode InteractiveServer` | server | yes |
| `/about` | none, so it is statically rendered | server | **none** |

Two details in that table are load-bearing and easy to undo by accident:

* **`/counter` and `/about` must have no `` at all.** Adding one is the documented workaround for the reported bug, so a page that has it cannot reproduce anything. You can tell these pages apart in the browser because the tab shows the address instead of a name.
* **The home page at `/` must live in the `.Client` project and render on WebAssembly.** The report that started this was written against exactly that arrangement.

Put a link to each page in the nav menu. Navigation has to happen by clicking links, because a typed address is a full page load and does not go through the code being fixed.

The metadata comments are what the fix is about, so make sure the page emits them. Add a component using `[PersistentState]` and a JavaScript initializer. Before testing, view the page source and confirm you can find comments beginning with:

```