Blazor WebAssembly MSAL 10.0.10 throws uninitialized_public_client_application after Firefox refresh; 10.0.7 works

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

After updating a Blazor WebAssembly application using the standard AddMsalAuthentication and Microsoft.Authentication.WebAssembly.Msal integration from 10.0.7 to 10.0.10, Firefox consistently fails after refreshing an authenticated protected route.

The browser console reports:
uninitialized_public_client_application: You must call and await the initialize function before attempting to call any other MSAL API.

The same application, authentication configuration, and test steps work when the complete Microsoft Blazor/WebAssembly/MSAL package set is pinned to 10.0.7.

### Expected Behavior

MSAL initialization should complete before Blazor requests authentication state, allowing the protected route to render after refresh.

### Steps To Reproduce

Run a Blazor WebAssembly application using the standard AddMsalAuthentication and Microsoft.Authentication.WebAssembly.Msal setup, with all relevant Microsoft Blazor/MSAL packages at 10.0.10.

Open the application in Firefox and authenticate. Navigate to an authenticated/protected route. Press F5 to refresh the page.

Actual result: The application fails with uninitialized_public_client_application.

Comparison: Change the complete Microsoft Blazor/WebAssembly/MSAL package set to 10.0.7 and repeat the steps. The error does not occur.

I can create a minimal public reproduction project if needed. Reproducing the actual MSAL authentication path will require configuring a disposable Microsoft Entra ID SPA app registration and localhost redirect URI;

### Exceptions (if any)

uninitialized_public_client_application: You must call and await the initialize
function before attempting to call any other MSAL API.

The stack trace originates from:
_content/Microsoft.Authentication.WebAssembly.Msal/AuthenticationService.js

### .NET Version

10.0.302

### Anything else?

Affected packages: Microsoft.Authentication.WebAssembly.Msal and related Blazor WebAssembly packages, version 10.0.10.
Working package set: all related packages pinned to 10.0.7.
Affected browser: Firefox.
Edge did not reproduce the problem or at least is masked it.
The application uses the standard AuthenticationService.js script reference and AddMsalAuthentication registration.
The problem reproduced locally and in a deployed test environment.

Sanitized Standard auth setup:
The relevant client setup is standard Blazor WASM/MSAL. No application-specific MSAL calls are made before Blazor starts.

// Program.cs
```
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;

var builder = WebAssemblyHostBuilder.CreateDefault(args);

builder.Services.AddMsalAuthentication(options =>
{
builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);

options.ProviderOptions.LoginMode = "popup";
options.ProviderOptions.Cache.CacheLocation = "localStorage";
});

await builder.Build().RunAsync();
```

wwwroot/index.html
```

```

App.razor
```

```

versions:
```

```

Inspect _content/Microsoft.Authentication.WebAssembly.Msal/AuthenticationService.js and the standard AddMsalAuthentication startup path first, reproducing the Firefox F5 flow with packages 10.0.10 and comparing against 10.0.7. Done means the authenticated protected route refreshes without uninitialized_public_client_application while preserving the standard setup.

Written by the indexing model from the issue text.