feat(i18n): add scoped i18n foundation with one migrated page (#2097)

Co-authored-by: Kandev Agent <agent@kandev.dev>

AGENTS.md

@@ -68,6 +68,29 @@ When you hit a limit: extract a helper function, custom hook, or sub-component.
 
 Every code change must include tests for new or changed logic. Backend: `*_test.go` files alongside the source. Frontend: `*.test.ts` files for utility functions, hooks, API clients, and store slices. Exceptions: config files, generated code, React component markup. Use `/tdd` for test-driven development.
 
+### Internationalization
+
+The web UI is localized with i18next (`namespace:key`). **All new user-facing copy
+must go through `t()` / `<Trans>`** — never a hardcoded literal — regardless of
+which directory you are in.
+
+The migration of existing strings is in progress, **one directory per PR**. The
+lint guard (`i18next/no-literal-string`) is an error, but only for the paths in
+`i18nGuardFiles` (`apps/web/eslint.i18n.options.mjs`), so unrelated PRs are never
+blocked by strings in code nobody has migrated. **When you migrate a directory,
+append it to that list in the same PR**; never remove an entry to make a build
+pass.
+
+Three rules that cause silent, hard-to-find bugs when broken: never translate a
+string compared with `===` (type-to-confirm tokens become impossible to type);
+never call `t()` at module scope (it freezes at the boot locale and the
+pseudo-locale cannot detect it); never pass an English plural ending as a value —
+use `count` with `_one`/`_other`. `pnpm run i18n:check` enforces the last two.
+
+A clean lint is not proof a file is done — the rule only sees plain literals in
+JSX. The pseudo-locale (Settings → General → Appearance, dev/e2e builds) is the
+completeness check. Full guide: [`docs/i18n.md`](docs/i18n.md).
+
 ### Knowledge
 - **Public docs:** Website-ready user documentation lives in `docs/public/**`. Use `/docs-maintainer` when a change affects CLI commands, config keys, install/deploy flows, workflows, executors, public APIs, screenshots, or user-facing terminology.
 - **Specs:** Feature specs live in `docs/specs/<slug>/spec.md` — the durable "what & why" of a feature, written before coding. Use `/spec` to write or update a spec. See `docs/specs/INDEX.md`.