[BUG]: UI proceeds with mutating request after failed login, leaking stale session state

[a-effort]

Bug

After a failed login (POST /auth/login returns 401), the UI still fires a subsequent mutating request. Submitting the "Connect MCP server" form triggers POST /gateways right after the login attempt failed. That request carries stale cookies from an earlier session, and the backend rejects it with a 403 CSRF error instead of anything indicating the user isn't logged in.

Console output:

auth/login:1  Failed to load resource: the server responded with a status of 401 (Unauthorized)
gateways:1    Failed to load resource: the server responded with a status of 403 (Forbidden)
POST http://localhost:8000/gateways 403 (Forbidden)

Cause

Login failure doesn't block the app. Subsequent authenticated actions can still fire using whatever session state is currently held in cookies, instead of being gated behind a confirmed successful login. Stale cookies from a prior session get reused on the next mutating call even though the user was never re-authenticated.

Expected Behavior

• A failed login shows a clear error ("invalid email or password") and stops there.
• No mutating request fires until login succeeds and a fresh session is confirmed.
• Stale auth state is cleared on login failure, not left for reuse.

Fix

• Gate form submission on a successful login response only.
• Clear leftover auth/session cookies or client state on login failure.
• Surface the actual 401 login error instead of letting an unrelated 403 CSRF error be the only visible symptom.

Companion backend issue for the CSRF-side misattribution (stale session cookie causing a misleading 403 instead of 401): IBM/mcp-context-forge (to be filed).