[Validation] Enhanced navigation no longer preloads WebAssembly assets

**Scenario contact:** @javiercn

## Scenario

**This scenario validates a deliberate behavior change, not a bug fix.**

When a page contains an `InteractiveWebAssembly` component, Blazor's `ResourcePreloader` emits `` elements in `` for the WebAssembly framework files. In .NET 10 it did that on **every** server-rendered response, including the ones served as an enhanced navigation. Two things went wrong as a result: the WebAssembly runtime does not restart on an enhanced navigation, so the hints were redundant after the first page, and the DOM merge added and removed the `` elements in an unstable order, which made some browsers issue extra preload requests.

In .NET 11 `ResourcePreloader` emits nothing when the response is an enhanced navigation. Three things are deliberately unchanged, and each is a check in its own right:

* The **first page load** still emits preload hints.
* A **full page reload** still emits them.
* Pages **without** an `InteractiveWebAssembly` component never emitted them and still do not.

## Minimum build

.NET 11 Preview 7 or later.

## Configurations to cover

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

Only `InteractiveWebAssembly` is ticked because it is the only render mode that ever emitted these hints. The framework checks for it explicitly, and the check excludes Interactive Auto, so an Auto page produces nothing to observe. Static SSR and Interactive Server pages are still needed in the app, as places to navigate from, but they are not what is being measured.

## 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 matters because the preload list is built from static web asset metadata, and published assets are fingerprinted, so the set of URLs differs from a development build.

## Setup

Have the same app on .NET 10 and on .NET 11, so you can compare directly. The .NET 10 build is what shows you the hints that used to be emitted; without it you are only confirming an absence.

## What to build

Create a Blazor Web App with `dotnet new blazor -int Auto`, interactivity per page, and add:

| Route | Render mode | Why |
|---|---|---|
| `/` | none, statically rendered | Somewhere to navigate from |
| `/wasm` | `@rendermode InteractiveWebAssembly` | The page that emits preload hints |
| `/auto` | `@rendermode InteractiveAuto` | Control: should emit nothing, before or after |
| `/server` | `@rendermode InteractiveServer` | Control: should emit nothing |

Put links to all four in the nav menu, and keep the interactive components trivial.

You are looking for `` elements in `` whose `href` points at `_framework/` files, such as `dotnet.js` and the `.wasm` payload. Inspect the live `` in developer tools rather than the original page source, because enhanced navigation patches the DOM after the fact.

## Things to try

Keep the network tab open, and inspect `` in the elements panel after each step.

* Load `/wasm` directly as the first page, and look at the preload links in ``. They should be there.
* From `/`, click the nav link to `/wasm`. This is the changed behavior.
* Do a full browser reload on `/wasm`. The hints should return.
* Navigate `/` to `/auto` and `/` to `/server`, confirming neither produces preload links either way.
* Navigate back and forth between `/` and `/wasm` several times, counting requests for `_framework/` files in the network tab.
* Repeat the whole sequence on .NET 10 and compare.
* Repeat against the published app, where the asset URLs are fingerprinted.

## Expected behavior

Preload hints appear on a first load and a full reload, and not on an enhanced navigation, and the WebAssembly app works the same either way.

### Must hold

* Loading `/wasm` directly emits `` elements for `_framework/` assets in ``.
* Reaching `/wasm` by clicking a nav link emits **no** such elements.
* A full browser reload of `/wasm` emits them again.
* `/auto` and `/server` emit no WebAssembly preload links, on first load or on navigation.
* The WebAssembly component on `/wasm` becomes interactive and works when reached by navigation, exactly as when loaded directly. The runtime is not re-fetched on the second and later navigations.
* Navigating between `/` and `/wasm` repeatedly issues no duplicated requests for `_framework/` files, and the count does not grow with each round trip.
* On .NET 10 the same navigation does emit the hints, confirming your setup reproduces the old behavior.

### Expected differences between configurations

* Published output uses fingerprinted asset URLs, so the `href` values differ from a development build. Whether the hints are present should not.

## Evidence to capture

The `` markup from developer tools in three states: `/wasm` on first load, `/wasm` reached by nav link, and `/wasm` after a full reload. Plus the network tab filtered to `_framework/` for a round trip between `/` and `/wasm`, on both .NET 10 and .NET 11.

## Documentation to use

* [Breaking change: Blazor enhanced navigation no longer preloads resources](https://learn.microsoft.com/aspnet/core/breaking-changes/11/blazor-enhanced-nav-preloading-disabled)
* [Enhanced navigation and form handling](https://learn.microsoft.com/aspnet/core/blazor/fundamentals/navigation?view=aspnetcore-11.0#enhanced-navigation-and-form-handling)

## 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.