Where should the blazor-environment value be injected for immutable Blazor WebAssembly builds?

In a Blazor WebAssembly standalone deployment, the client resolves its host environment from the blazor-environment meta tag in index.html rather than from the server's ASPNETCORE_ENVIRONMENT variable. When the published artifact is immutable, that tag is baked at build time, so the same artifact cannot serve different environments without host-level rewriting of index.html or a separate build per environment.

The client loads wwwroot/appsettings.json plus appsettings.{Environment}.json based on the resolved value. A key present only in appsettings.Development.json will be missing when the browser environment resolves to Production, causing configuration failures that do not appear during local development where the tag may still carry Development.

For immutable, single-artifact deployments targeting multiple stages (staging, production, etc.), the injection point for the environment value remains an open architectural decision. The value could be supplied by a reverse proxy rewriting the meta tag, by a build-time transform per environment, or by a runtime fetch from a separate configuration endpoint.

Which injection strategy preserves immutable artifacts while allowing per-stage environment resolution? Does a runtime fetch from a configuration endpoint introduce unacceptable latency or complexity compared to host-level HTML rewriting? What are the trade-offs when the same artifact must serve both prerendered and fully client-side requests in Auto mode?