[Validation] Blazor Web startup options format in the Server and WebAssembly scripts

**Scenario contact:** @javiercn

## Scenario

Blazor apps configured startup differently depending on which script they loaded. With `blazor.web.js` the options are grouped, `{ ssr: {...}, circuit: {...}, webAssembly: {...} }`, but with `blazor.server.js` or `blazor.webassembly.js` the runtime-specific options were top-level properties instead. Guidance and samples written for one kind of app did not apply to another, and a block of options could not be moved between them. ([#51611](https://github.com/dotnet/aspnetcore/issues/51611))

.NET 11 accepts the grouped format in all three scripts. This validates that the grouped format now works everywhere, and that apps written the older flat way keep working untouched.

## Minimum build

.NET 11 Preview 7 or later.

## Configurations to cover

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

## Also exercise

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

Alongside the app types in the list above, building a Blazor Server app that loads the server script directly is worthwhile, since that is the other place these options are written.

## What to build

A standalone WebAssembly app that configures its own startup: set the logging level, supply the environment, and hook into the startup process so you can tell from the console that your configuration ran. Write these options in the newer nested style. Then make a second copy that writes the same options in the older flat style, and a third that mixes the two, setting some options one way and some the other. Do the same for a Blazor Server app that loads the server script directly, so you can compare the two app types.

## Things to try

* Running each copy and comparing what the console shows.
* Setting the same option in both styles at once with different values, to see which wins.
* Writing an option name that does not exist, or misspelling one.
* Copying a block of options from the Blazor Web App documentation into the standalone app unchanged.
* Publishing the apps and running the published output.
* Looking for documentation that tells you which style to use, and noting how easy it was to find.

## Expected behavior

One block of startup options can be written once and used in any app type, and existing apps are unaffected.

### Must hold

* The same block of options written in the newer nested style is accepted by each app type covered, without being rewritten between them.
* An app written in the older flat style keeps working, with no new warning and no change in behavior.
* Where both styles set the same option, the outcome is the same on every run rather than depending on the order the options appear in.
* An option name that does not exist fails in a way a developer can notice, rather than being silently ignored.

### Expected differences between configurations

* No differences are expected.

## Documentation to use

* [Blazor startup options release notes](https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-11#blazor-web-script-startup-options-format-now-supported-for-blazor-server-and-blazor-webassembly-scripts)
* [ASP.NET Core Blazor startup](https://learn.microsoft.com/aspnet/core/blazor/fundamentals/startup?view=aspnetcore-11.0)
* [ASP.NET Core Blazor logging](https://learn.microsoft.com/aspnet/core/blazor/fundamentals/logging?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.