Localize the browser identity console

Add first-class browser localization for English (en), Norwegian Bokmål (nb), and Danish (da), with room to add Norwegian Nynorsk (nn) later, without changing API contracts, authorization, audit semantics, or credential/session handling. Scope - Localize all user-facing browser UI: login, registration/setup, authorization/error pages, admin overview, organizations, users/access management, shared layout/components, and the local invitation email. - Store the durable account preference on `platform.users.locale`. Also keep a separate validated browser preference cookie so login and other anonymous flows remember an explicit choice before authentication. - Resolve browser pages from the explicit browser cookie first, then the authenticated account locale, then Accept-Language, with English fallback. Provide a no-JavaScript language selector. - Render the document language and localized accessibility labels, validation/errors, plurals/counts, and UTC timestamps. - Use the user’s persisted locale for invitation mail and setup-link pages. Account creation must capture an initial preferred locale; authenticated locale changes update both the user and browser cookie. Constraints - Keep API error codes, machine action/event names, persisted business data, audit reasons, logs, documentation, CLI diagnostics, and developer-only strings stable/English unless separately scoped. - Locale must never be trusted from an unchecked header/query/database value. Preference cookies remain host-only, Secure on HTTPS, SameSite=Lax, path-rooted, and unrelated to authentication. The selector preserves origin/CSRF protections and permits only safe same-origin returns. - Anonymous email submission must not change a known account’s locale: knowledge of an email address is not authorization to mutate profile preferences. - Use the existing server-rendered Maud/native-form design; no client-side translation catalog or JavaScript dependency. Keep translation content typed/compile-time checked rather than adding a generic framework. Acceptance criteria - Every in-scope browser response and local invitation email is complete in en, nb, and da; no mixed-language common UI remains. - Explicit browser selection persists across anonymous/login flows. Authenticated selection persists to both the account and browser; account locale supplies the initial preference on browsers without an explicit cookie and determines invitation mail/setup language. Malformed values safely fall back to English. - Existing security behavior (canonical origin, CSRF, session rotation, safe redirects, token secrecy, audit/outbox atomicity) remains unchanged. - Unit/integration/browser coverage validates negotiation, cookie/redirect validation, catalog completeness/formatting, all three locales, persisted account preference, localized mail/setup behavior, accessibility names, responsive layout, and JavaScript on/off behavior.