feat(i18n): add Korean (ko) translation

[moduvoice]

Motivation

This adds Korean (ko) translation support — to help Korean-speaking users use this
open-source project more comfortably in their own language.
(한국 사람들의 오픈소스 이용에 도움이 되게 하기 위해서 한글화 작업을 하였습니다.)

Changes

• Add full Korean translation for all 24 namespace files under packages/web/i18n/ko/, the main app's product-facing i18n directory (shared by projects/app and projects/marketplace via localePath). This is the app's real UI i18n system — distinct from document/i18n, which only covers the documentation site. Translated from the English (en) source with exact key parity (3,634 keys, verified programmatically) and all {{placeholder}} / HTML-like tag interpolations preserved.
• Register the new locale end-to-end so it's actually usable, not just data files:
  • packages/global/common/i18n/type.ts: add ko to LangEnum, LocaleList, and langMap (with a new Korean flag icon, common/language/Korea.svg, registered in the icon manifest).
  • projects/app/next-i18next.config.js, projects/app/next.config.ts, projects/marketplace/next-i18next.config.js: add ko to the locales array.
  • packages/web/i18n/utils.ts: map browser locale strings (ko, ko-KR) to the app's ko locale, including the smart-fallback path.
  • projects/app/.../useChatLanguageSwitch.ts: add ko to the shared-chat language switcher's fixed locale list.
• Harden getModelProvider() in both projects/app/src/web/common/system/useSystemStore.ts (client) and packages/service/core/app/provider/controller.ts (server): both indexed a provider name/avatar cache map that is only pre-built for the historical three locales. Calling them with any other locale (including the new ko) would throw Cannot read properties of undefined — this is exercised by many core screens (model config table, channel edit, model dashboard/logs, chat model selector, TTS select, etc.) via i18n.language. Both now fall back gracefully to the default provider info instead of throwing.

Note on scope: packages/global/common/i18n/type.ts also has a much smaller, separate I18nStringType (en required, zh-CN/zh-Hant optional) used for a handful of inline, hardcoded content strings scattered across the codebase (e.g. a few sandbox tool descriptions, one workflow template's sub-app names, the custom error page). I deliberately left that type untouched — extending it would mean hand-editing many unrelated files' hardcoded content rather than adding a translation. Since that type already falls back to en for any locale it doesn't recognize (the same pattern used for zh-Hant→zh-CN), Korean users see the English text there instead of a broken value — a small, contained, and honest gap rather than a functional problem.

Testing

• Programmatically verified all 24 ko/*.json files have exact key parity with en/*.json (3,634 keys, en count == ko count, zero missing/extra keys in either direction).
• Programmatically verified all {{variable}} and <tag>...</tag> interpolation placeholders are preserved (as a multiset per key); the only differences found were a few English source strings themselves duplicating a placeholder multiple times inconsistently (likely a pre-existing bug in the English audit-log strings) — the Korean text uses every unique placeholder needed, just without the redundant repeats.
• Manually traced every runtime call site that reads the locale list (LocaleList, langMap, chatLanguageList, getLangMapping) to confirm none assume a fixed 3-locale set; found and fixed the two getModelProvider call sites described above that did.
• Could not run the project's own pnpm test / pnpm lint in this environment (fresh clone, no node_modules, and this is a large pnpm-workspace monorepo); the change set is limited to translation JSON plus small, self-contained TypeScript/config edits that were reviewed by hand.

🤖 Generated with Claude Code

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}