i18n: add Korean (ko) translation

[moduvoice]

Korean (ko) translation PR body template

Motivation

This adds Korean (ko) translation support — to help Korean-speaking users use this
open-source project more comfortably in their own language.

한국 사람들의 오픈소스 이용에 도움이 되게 하기 위해서 한글화 작업을 하였습니다.

Changes

• Added packages/apostrophe/modules/@apostrophecms/i18n/i18n/ko.json — full Korean translation of the core admin UI (776 keys, matching the English source's key set and order exactly).
• Added packages/ai-helper/i18n/aposAiHelper/ko.json — full Korean translation of the AI Helper module (19 keys, matching the English source's key set and order exactly).
• Added a changeset (.changeset/add-korean-i18n.md) covering both packages, following the same format as other merged changesets in this repo.
• No central locale registry needed to update — Apostrophe's i18n module auto-discovers any <locale>.json file placed in a module's i18n/ directory (and in i18n/<namespace>/ for namespaced modules) and registers it with i18next by filename, exactly like the existing de, es, fr, it, pt-BR, and sk locales.

Testing

• Programmatic key-parity check: both ko.json files have 0 missing / 0 extra keys vs. their en.json counterparts, and key order matches exactly.
• Verified all {{ variable }} interpolation placeholders and embedded HTML tags (e.g. <strong>) are preserved identically between English and Korean values for every key (0 mismatches).
• Verified _plural suffix keys are correctly retained (i18next requires the key structure even though Korean has no grammatical plural); where the English singular hardcodes "one" instead of {{ count }}, the Korean singular correctly hardcodes "1" to match, and where English singular/plural both use {{ count }}, the Korean values are identical for both, as expected.
• Spot-checked terminology consistency across the full file for domain terms: Pieces → 피스, Slug → 슬러그, Draft → 초안, Publish → 게시, Archive → 보관, Localize → 현지화 — all applied consistently everywhere they occur.
• Verified the two dayjs*Format keys that other locales customize (dayjsTitleDateFormat, dayjsMediaCreatedDateFormat) use valid Korean date conventions (e.g. YYYY.MM.DD), while the two sentinel keys (dayjsCellDateFormat, dayjsRelativeTimeFormat) are correctly left as "apostrophe" (a special sentinel value read by the admin UI to trigger its own built-in fallback formatting), matching the convention already used by every other shipped locale.

[BoDonkey]

Thank you for this submission. Can I ask how you came upon ApostropheCMS? We are always interested in branching out into new areas and hadn't run across any Korean sites using it, yet.

[BoDonkey]

I should also say that I think I will have some issues reviewing this PR. I can, of course, verify the fidelity of the translation strings using an LLM. Where I will have an issue is in reviewing the display of the characters properly in the Admin UI. Have you verified and used the ApostropheCMS Admin UI with Hangul?