feat: add project-wide i18n support

[NAO-200]

Summary

Adds UI internationalization (English + German): shared locale JSON, vue-i18n on the frontend, i18n error keys on the backend, and per-user UI language stored in the DB.

Also fixes #251 (users could override protected system settings via appSettingSet) and implements #250 (optional restriction of language selection per role).

---

Changes

• utils/modules/i18n/ — EN/DE catalogs; i18n-bundles.js bundles namespaces for vue-i18n (renamed from messages.js); backend uses catalogs for logs.
• Frontend: $t / i18n-t, resolveApiMessage, translateMaybeKey, formatLocalized* for dates
• Backend: TranslatableError, structured { key, params } in socket responses
• Backend English output: translateMaybeKey in backend/utils/i18n.js
• Transform migrations: DB seed strings → i18n keys (settings, placeholders, templates, …)
• UI language: app.locale in setting (default) + user_setting (per user); logged-in users read merged appSettings from server, with localStorage (locale) until settings load, fallback en; auth pages use browser language and clear cache when logged out; save via Preferences → appSettingSet + cache; App.vue applies locale on appSettings; helpers in locale.js + utils.js
• Docs: docs/source/for_developers/i18n.rst with developer patterns and docs/source/for_researchers/interface_language.rst for researchers

---

Out of scope

Not fully done in this branch:

• Workflows
• Settings dashboard
• Setup wizard (SetupWizard, components/wizard/*)
• User rights UI (RoleManagementModal, …)
• Some admin-only dashboards/modals
• Assignments / Submissions cluster
• Unify utils/modules/i18n/index.js and backend/utils/i18n.js — works as-is, duplication only in helper code

---

#250 — Restrict language selection

New right: frontend.preferences.disableLanguageSelection (default on Guest).

• Hides language block in Preferences
• Blocks saving app.locale via appSettingSet (non-admin)
• Admins unaffected; can still set locale for users

---

#251 — Security: system settings override

Users could write any key to user_setting and shadow system setting values.

• New column setting.allowUserOverride (default false; true only for allowed keys like app.locale, projects.default, …)
• user_setting beforeCreate / beforeUpdate hooks reject protected keys
• Admins bypass via bypassSystemSettingCheck when setting prefs for users

---

[karimouf]

There were a lot of files changed, very hard to look at everything, but in general looks fine from my point of view. Don't forget to add docstrings and specify which files you said were incorrectly merged

[dennis-zyska]

flattenObject, interpolate, and hasKey are already implemented in utils/modules/i18n/index.js, the shared module this PR adds. Use it directly instead: const { t, hasKey, messages } = require('../../utils/modules/i18n');.

[NAO-200]

Agreed, the duplication is real.
This split came from TPSE: shared JSON catalogs, frontend via Vite/ESM (i18n-bundles.js), backend via fs in backend/utils/i18n.js. utils/modules/i18n/index.js looks like an intended shared entry, but Node can’t require it as is because en/index.js is ESM, so the backend helper stayed separate. I’m not sure whether that was intentional or leftover.
Unifying the helpers needs a small refactor. I’d keep this PR on finishing the i18n port and track that in #273, unless you want it in scope here.

[bingobongomann]

i think this should use the MetaModel.getByKey instead of findOne directly.

[bingobongomann]

I think the brackets { TranslatableError } here will cause the import to be deconstructed which will cause the direct class export of TranslatableError.js:75 to be deconstructed which will return undefined and cause a TypeError when instantiated with new ...

As far as i can tell the import is done correctly in the actual code, but here in the docs the { } brackets are added.