fix(ui): redirect to login on 401 token_not_found_in_db

[songkuan-zheng]

Summary

The dashboard UI never redirects to the login page on 401 errors with
error.type=token_not_found_in_db (and other auth-error types in
AUTH_ERROR_TYPE_TO_ACTION that map to REDIRECT_LOGIN). Users get a
silent toast and stay on a broken page with stale cookies.

Two-part fix.

Patch 1 — root cause

178 fetch callsites in networking.tsx and src/app/(dashboard)/hooks/
were calling:

const errorMessage = deriveErrorMessage(errorData);
handleError(errorMessage);   // ← string

handleError's D1 type-aware fast path (networking.tsx:507-544)
calls extractErrorType(), which explicitly rejects strings
(networking.tsx:391). So the type-aware dispatch never fired,
even though the infrastructure was already there.

Now callsites pass the raw errorData object; handleError can
read error.type and route auth errors to REDIRECT_LOGIN.

Patch 2 — defense in depth

SESSION_EXPIRED_SIGNALS listed "Authentication Error - Invalid"
(dash) but the backend's token-not-found path emits
"Authentication Error, Invalid" (comma). Added the comma variant
so the string-marker fallback also catches it when the structured
type field is absent (older backend builds, exotic error paths).

How the fix works end-to-end

fetch site
  └─ if (!response.ok)
       └─ handleError(errorData)                    ← Patch 1
            └─ extractErrorType(errorData)
                 └─ "token_not_found_in_db"
                      └─ AUTH_ERROR_TYPE_TO_ACTION
                           └─ "REDIRECT_LOGIN"
                                └─ clearTokenCookies()
                                └─ window.location.href = "/ui/"

Test plan

• vitest run: 475 / 475 passing — including the
  networking.test.ts:394 assertion that has documented the intended
  token_not_found_in_db → REDIRECT_LOGIN behavior since landing (the
  assertion now matches production behavior, not just spec).
• useAccessGroups.test.ts updated — the asserted handleError
  argument changed from the derived message string to the raw error
  object, matching the new contract.
• next build (production) — clean compile, all 50+ route pages
  pre-render.
• e2e Docker image build (e2e/tools/proxy build) — picks up the
  source changes via the in-Dockerfile UI rebuild step (Dockerfile:50-79).
• Browser E2E against e2e proxy:
  • login with master key
  • inject fake JWT (valid format, key field points to a non-existent
    virtual key) into the token cookie via DevTools
  • navigate to /ui/?page=teams
  • React fires /team/list, /organization/list, /user/available_users,
    /v2/guardrails/list, etc. in parallel
  • backend returns 401 with type=auth_invalid_credentials (also in the
    REDIRECT_LOGIN map)
  • browser navigates: /ui/?page=teams → /ui/ → /ui/login/?redirect_to=...
  • cookies cleared, login form rendered
  • The 401 message ("Authentication Error, LiteLLM Virtual Key expected...")
    does NOT match any SESSION_EXPIRED_SIGNALS marker, so this redirect
    is reachable only via the structured-type channel introduced by
    Patch 1. Confirms the fix's contract end-to-end.

Bonus fix in this PR

networking.tsx:7341+ — the MCP tool-call error path declared
errorData inside a try block, so the bulk replacement referenced
an out-of-scope variable. Hoisted let errorData: any = null outside
the try; handleError(errorData ?? responseText) falls back to raw text
when JSON parsing fails. (Discovered during the Docker UI rebuild,
caught by Next.js' TypeScript pass.)

Risk

Near-zero:

• handleError signature is already string | any — accepts both.
• extractErrorType already handles typeof === 'string' (returns null).
• No control-flow changes; only the parameter type at callsites.
• The triggering mechanism (triggerSessionExpiredRedirect,
  window.location.href, clearTokenCookies) is unmodified.