[Validation] Setting WebAssembly culture, environment and variables from the server

**Scenario contact:** @javiercn

## Scenario

The WebAssembly part of a Blazor Web App has traditionally been hard to configure per visitor. Its environment, its culture and any settings it reads all had to be baked in or fetched after it had already started. This validates that the server can decide these before the app starts in the browser, so each visitor's app comes up already set up for them.

## Minimum build

.NET 11 Preview 7 or later.

## Configurations to cover

* Blazor Web App
* [ ] Static SSR
* [ ] Interactive Server
* [x] Interactive WebAssembly
* [x] Interactive Auto
* [ ] Standalone WebAssembly
* [ ] 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

The app needs resources for at least two languages so that a culture change is visible, and something in the UI that behaves differently between environments.

The properties this scenario exercises live under `BrowserOptions.InteractiveWebAssembly`:

* `ApplicationCulture`
* `EnvironmentName`
* `EnvironmentVariables`, a dictionary the server fills in

They are set through `MapRazorComponents().WithBrowserOptions(...)` in server startup, or per request through a `` component in the page.

## What to build

A Blazor Web App whose WebAssembly side has its culture, environment and a couple of environment variables decided by the server. Show all of these on a page: the environment the app believes it is in, the culture it formats dates and numbers with, some translated text, and the values it read from its environment variables.

Make the choices depend on the request, for example taking `ApplicationCulture` from the signed-in user's profile or a preference cookie, and `EnvironmentName` from a query string, so that different visitors get different answers. Include a page whose content is environment-dependent so the effect is visible in the UI rather than only in a debug readout.

## Things to try

* Loading the app with each culture and checking dates, numbers and translated text.
* Loading with each environment and checking the environment-dependent content.
* Changing the preference that drives the culture, then reloading.
* Opening two browsers at once with different preferences.
* Comparing the first render of the page with what appears once the app is running in the browser.
* Giving `ApplicationCulture` a culture the app has no translations for.
* Giving `EnvironmentName` a value of your own invention rather than a standard one.
* Setting several `EnvironmentVariables`, including one with an empty value.
* In Interactive Auto, the first visit and a later visit once the app has been cached.
* Navigating to a WebAssembly page rather than loading it directly, so startup happens after an enhanced navigation.

## Expected behavior

The WebAssembly side comes up already set up for this visitor, without a visible correction afterwards.

### Must hold

* The WebAssembly side reports the culture, environment and environment variables the server chose from its first render, without visibly correcting itself afterwards.
* Dates and numbers format according to `ApplicationCulture`, and translated text appears in it.
* Two browsers with different preferences receive different results at the same time.
* A culture with no translations falls back as it would otherwise, and an `EnvironmentName` of your own invention is accepted as given.
* A WebAssembly page reached by navigation gets the same values as one loaded directly.

### Expected differences between configurations

* In Interactive Auto the first visit runs on the server and later visits run in the browser, so note whether the culture, environment and variables match across both.

## Documentation to use

* [ASP.NET Core Blazor globalization and localization](https://learn.microsoft.com/aspnet/core/blazor/globalization-localization?view=aspnetcore-11.0)
* [ASP.NET Core Blazor environments](https://learn.microsoft.com/aspnet/core/blazor/fundamentals/environments?view=aspnetcore-11.0)
* [ASP.NET Core Blazor configuration](https://learn.microsoft.com/aspnet/core/blazor/fundamentals/configuration?view=aspnetcore-11.0)

The API names above were taken from the shipped code, not from docs. If you cannot find this documented anywhere, say so in the report.

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