i18n: typed translation keys – an unknown t() key fails the type-check #911

Goal

Calling t("some.key") with a key that does not exist in the English resources is a TypeScript error.

Context

• ~1,087 t(...) calls in apps/smart-ssh-community/frontend/src; nothing checks that the key exists in locales/en/common.json. i18n.ts:107 only sets fallbackLng; there is no CustomTypeOptions declaration and no missing-key handler.
• Some keys are built dynamically (e.g. translateErrorCode in errorCodes.ts uses t(`errors.${code}`); the locale-driven language names).
• Extensions register their own namespace (resource bundles added at runtime); their keys are not in common.json.

Requirements

• Add src/i18next.d.ts with declare module "i18next" { interface CustomTypeOptions { defaultNS: "common"; resources: { common: typeof import("./locales/en/common.json") } } } (adjust to the installed i18next/react-i18next version).
• Fix all type errors: real typos are fixed; dynamic keys use a typed helper (e.g. a function that takes a union of known error codes) or a narrowly scoped cast with a comment (as ParseKeys), not a global any.
• Extensions keep working: t calls with an explicit other namespace ({ ns: "…" } / useTranslation("…")) must still type-check; document the pattern for extension namespaces in docs/ (i18n section) or the i18n.ts header.
• In development builds, log missing keys once (saveMissing/missingKeyHandler with console.warn); production unchanged.
• Measure type-check time before/after and note it in the PR; if it more than doubles, use i18next's recommended ParseKeys limits (e.g. resources with as const JSON import or enableSelector) to bring it down.

Acceptance Criteria

• tsc (the frontend type-check script) fails for t("does.not.exist") (a type-level test file using // @ts-expect-error proves it) and passes for the whole code base.
• No new any casts for t; each remaining cast has a comment.
• Extension namespaces still type-check (test or example in the type-level test file).
• npm run lint, type-check and npm test pass; type-check duration before/after in the PR.

Technical Notes

• Frontend only. germanTextGuard.test.ts and the locale parity test stay as they are.

Spec impact: none

Related Work

• –