#21: guard the web surfaces and connect them to the auth service

Three separate gaps, all of which made the F4 interface non-functional or
unprotected:

The admin console rendered for anyone. There was no middleware and no
guard in the layout, so /admin/dashboard returned 200 unauthenticated -
only its data calls failed. middleware.ts now redirects both surfaces to
their login when the session cookie is missing, expired, carries the wrong
audience, or is a pre-MFA challenge token. It reads the claims without
verifying the signature on purpose: the signing key belongs to the auth
service and must not reach the browser bundle. That is sound because this
is not the boundary - every /api/v1 request is verified for real upstream.

Nothing served /api/v1/*. next.config.ts had no rewrites and there were no
route handlers, so every call the pages made 404'd against the Next
server, while AUTH_SERVICE_URL sat unused. A catch-all route now proxies
to the auth service, forwarding the client address and preserving multiple
Set-Cookie headers, which logout needs to clear both surfaces. Session
cookies also move to Path=/, since a cookie pinned to /user or /admin was
never sent with the /api/v1 requests that needed it.

i18n existed only as files. The three bundles had perfect key parity and
real translations, but no library, no imports and no switcher: the UI was
hardcoded English and i18n.test.ts compared keys while the feature was
absent. There is now a provider, a hook, a language switcher, and
server-side Accept-Language negotiation that honours q-values and matches
a bare "pt" to pt-BR. Logins, both layouts and the settings screen consume
it; the admin pages still have English titles.

The settings screen invented app passwords in the browser with Math.random
and never stored them. It now calls the API, which returns the password
once and keeps only its hash.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

services/webmail/src/i18n/provider.tsx

@@ -0,0 +1,52 @@
+"use client";
+
+import React, { createContext, useCallback, useContext, useMemo, useState } from "react";
+import { LOCALE_COOKIE, MESSAGES, DEFAULT_LOCALE, translate, type Locale } from "./config";
+
+interface I18nContextValue {
+  locale: Locale;
+  setLocale: (locale: Locale) => void;
+  t: (key: string) => string;
+}
+
+const I18nContext = createContext<I18nContextValue | null>(null);
+
+export function I18nProvider({ locale: initialLocale, children }: { locale: Locale; children: React.ReactNode }) {
+  const [locale, setLocaleState] = useState<Locale>(initialLocale);
+
+  const setLocale = useCallback((next: Locale) => {
+    setLocaleState(next);
+    // Persisted for the next server render, so the page does not come back in
+    // the previous language on reload. Not HttpOnly: this is a display
+    // preference the client itself sets, carrying nothing sensitive.
+    document.cookie = `${LOCALE_COOKIE}=${next}; Path=/; Max-Age=31536000; SameSite=Lax`;
+    // Best effort: keep the account's stored locale in step for anything the
+    // server sends by mail. A failure here must not break the UI switch.
+    void fetch("/api/v1/user/locale", {
+      method: "PUT",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({ locale: next }),
+    }).catch(() => undefined);
+    document.documentElement.lang = next;
+  }, []);
+
+  const value = useMemo<I18nContextValue>(() => {
+    const messages = MESSAGES[locale] ?? MESSAGES[DEFAULT_LOCALE];
+    return { locale, setLocale, t: (key: string) => translate(messages, key) };
+  }, [locale, setLocale]);
+
+  return <I18nContext.Provider value={value}>{children}</I18nContext.Provider>;
+}
+
+export function useI18n(): I18nContextValue {
+  const ctx = useContext(I18nContext);
+  if (!ctx) {
+    throw new Error("useI18n must be used inside <I18nProvider>");
+  }
+  return ctx;
+}
+
+/** Shorthand for components that only need to translate. */
+export function useTranslations(): (key: string) => string {
+  return useI18n().t;
+}