Built-in i18n with locale-aware formatters (extends format helpers)

[MUKE-coder]

Problem

Going international is a 2-week project per app: pick i18next, set up extraction, refactor every string, swap formatters. Frameworks that ship i18n end-to-end (Next.js, Phoenix Gettext) make global launch a config flag.

Proposal

Built-in:

• `@grit/i18n` package with namespace-scoped translations
• `useT("namespace")` hook → `t("key", vars)` works in any component
• Backend `t(c, "key", vars)` for emails / receipts / WhatsApp messages — picks locale from user profile
• String extraction CLI: `grit extract-translations` walks the codebase, updates locale JSON files
• Formatters auto-locale-aware (extends issue Ship formatCurrency / formatDate / humanize / initials in the frontend stdlib #33): `formatCurrency(amount, "UGX", { locale: "en-UG" })`
• RTL support built into AppShell (<AppShell> with grouped sidebar + topbar + <PageHeader> as the dashboard default #23) — toggling Arabic flips the layout
• Translation admin UI: non-devs can edit copy without a deploy

Why this is differentiating

Apps built on Grit can ship to a new country in days, not months. For a Uganda-built framework, this is a strong narrative — African markets need multi-language as table stakes (English / Swahili / French / Arabic).

Acceptance

• A fresh app supports English + Swahili out of the box
• Adding a new locale is a JSON file + one config line
• Receipts / invoices PDFs render in the user's locale automatically