Translate the four keys that render as their own name

[ramonski]

A sweep of every t("...") in the frontend against the locale files found five keys with no translation. Two of the seven matches were i18next plural forms and one was a JSDoc example; four were real.

The visible one is the Settings → General language heading. It renders as the literal lower-case string language, in all four languages, and its guard could not have helped:

{t("language") || "Language"}

i18next returns the key when it cannot find a translation, so this evaluates to "language", which is truthy — the fallback never ran. Confirmed against the real library:

t("tray")                   -> "Ablage"
t("language")               -> "language"
t("language") || "Language" -> "language"
t("x", "Standardwert")      -> "Standardwert"

The same shape sits two hundred lines up on t("tray"), harmless only because that key happens to exist. Both are gone now that the keys are there.

clocks:capture reached an iconOnly button, where Button passes children through as aria-label. Nothing looked wrong; a screen reader simply said "capture".

customers:editContract and projects:taskLabel used i18next's defaultValue argument, which does work, so they read correctly in English and were untranslated in the other three.

The JSDoc example in ToggleField pointed at externalEditorEnableHint, which does not exist; the real key is externalEditorHelp.

All four keys added in en, de, es and ru. Parity holds at 0 missing per language, no t() in the source is unresolved apart from the plural forms, tsc is clean, and the four strings are in the built bundle.