CORS blocked HotReload module when using Aspire DevTunnel with Blazor WebAssembly (dynamic import fails)

Summary
When running a Blazor WebAssembly app with Hot Reload behind an Aspire DevTunnel (devtunnels.ms origin), the browser blocks the HotReload runtime module loaded from due to missing CORS headers. This prevents the dynamic import of and breaks Hot Reload / app startup.

Environment
• Project type: Blazor WebAssembly (ASP.NET Core hosted) with Hot Reload enabled
• Tunnel provider: Aspire DevTunnel (domain pattern )
• Local dev server: (Kestrel / ASP.NET Core dev server)
• Browser: Chromium-based (error shown in console)
• Observed on: local development machine using dev tunnel to expose local site

Steps to reproduce
1. Start the ASP.NET Core backend and Blazor WebAssembly app locally (listening on ) with Hot Reload enabled.
2. Expose the local site through Aspire DevTunnel so the public origin is something like .
3. Open the tunneled URL in a browser.
4. Observe console errors and failed module load.

Actual behavior
Browser console shows CORS error and module load failure:

Hot Reload module is requested from while the page origin is the devtunnel domain, so the browser blocks the request because the response lacks .

Expected behavior
The Hot Reload module should load successfully when the app is accessed via the dev tunnel. Either:
• The dev server should respond with the appropriate CORS headers allowing the devtunnel origin, or
• The dev tunnel should proxy requests so the browser sees same-origin responses, or
• The Hot Reload client should request the module from the tunneled origin rather than .

Temporary workarounds
• Access the site directly via (no tunnel) to avoid cross-origin requests.
• Manually enable permissive CORS on the local dev server during development (e.g., allow or ) — note: only for local dev, not production.
• Disable Hot Reload if that avoids the dynamic import (loses Hot Reload functionality).

Suggested fixes / investigation pointers
• Ensure the dev server (Kestrel / ASP.NET Core) includes for requests coming from the devtunnel origin. This can be done by configuring CORS middleware to allow the tunnel origin(s) during development.
• Alternatively, have the dev tunnel proxy the Hot Reload static content so the browser requests the module from the same tunneled origin instead of .
• Investigate why the Hot Reload client resolves the module URL to when the page origin is the devtunnel domain; consider making the Hot Reload client use relative or tunneled URLs when behind a proxy/tunnel.
• Consider adding guidance to documentation for using Hot Reload with dev tunnels (example CORS config or recommended tunnel proxy settings).

Additional information
• This appears specific to dynamic module imports used by the Hot Reload runtime and how the runtime constructs the module URL.
• Reproducible consistently when using Aspire DevTunnel (tunneled origin differs from ).
• Console stack traces and network request details are attached above; I can provide a HAR or screenshots if helpful.