FIX: surface auth config fetch failures instead of treating them as auth-disabled

[fei (feiiiiii5)]

Root Cause

fetchAuthConfig() in frontend/src/auth/msalConfig.ts collapsed both non-2xx responses and network errors into an empty AuthConfig. AuthProvider reads an empty config as "authentication disabled", so a transient failure of /api/auth/config rendered the normal app shell while protected APIs returned raw Missing or invalid Authorization header text. There was no login control, error surface, or recovery path (#2441).

Fix

The two failure paths in fetchAuthConfig now throw with contextual messages instead of returning an empty config. Wrapped network errors preserve the original error as their cause.

AuthProvider renders its Authentication Error page for these failures and now tells users to reload the page to try again. A 200 response carrying an empty config still means auth is disabled for local development, and that path is unchanged.

Test

• Updated the two fetchAuthConfig tests that asserted the old swallow behavior. Non-2xx and network errors now reject with contextual messages, and the network test verifies the original error is preserved as the cause.
• Updated the AuthProvider error-state test to verify the reload guidance.
• msalConfig.test.ts and AuthProvider.test.tsx: 22/22 passing locally.
• Verified in a browser that a failed config request renders the Authentication Error page with reload guidance, and that reloading recovers after the backend becomes available.

Diff Scope

• frontend/src/auth/msalConfig.ts: surface config fetch failures and preserve network error context
• frontend/src/auth/msalConfig.test.ts: cover HTTP failures, network failures, and error cause preservation
• frontend/src/auth/AuthProvider.tsx: add reload guidance to the authentication error state
• frontend/src/auth/AuthProvider.test.tsx: verify the reload guidance

Development was AI-assisted with human review of all changes.

Fixes #2441