add-app-language

# Add App Language ## Core principle Treat a new language as a cross-runtime compatibility feature. Define one locale contract, then make application resources, browser manifests, auxiliary locale libraries, and tests agree with it. ## Workflow 1. Establish the current baseline and locale contract. - Run `git status --porcelain` and preserve unrelated work and index state. - Inspect `src/constants/i18n.ts`, `src/utils/i18n/`, `src/components/LanguageSwitcher.tsx`, `i18next.config.ts`, `src/locales/`, `src/public/_locales/`, `tests/utils/i18nLocaleValidation.test.ts`, and nearby language-specific tests. - Search for locale-keyed runtime data and fallback resolvers outside `src/locales/`, including public JSON. Use the owning project workflow for independently managed surfaces instead of changing their translation or fallback contract incidentally. - Use current code, directories, and tests as the source of truth. Treat hard-coded language or namespace counts in prose as potentially stale. - Decide the canonical BCP 47 application tag, accepted browser or stored aliases, language-family and regional fallback behavior, Chrome underscore locale identifiers, documentation fallback, and available Day.js, date-fns, and natural-date parser support. - Ask only about unresolved choices that materially affect stored preferences, regional resource sharing, manifest coverage, documentation scope, or new dependencies. Reuse user decisions and established locale conven...