feat(i18n): consume versioned translation resources for eight-locale homepage

[seonghobae]

Buyer gap

The published homepage currently carries its translation authority inside i18n.js and exposes only KO/EN. That makes UI strings—including accessibility-only text such as external-link context—part of the browser source bundle and leaves JA/ZH/VI/ES/DE/FR without a canonical product contract.

This issue owns the website consumer migration, not the organization-wide translation domain itself. The canonical translation-ledger owner must be decided through the existing enterprise-architecture path rather than silently invented here.

Architectural constraints

• Translation authority is a versioned database resource addressed by stable screen/resource keys; the browser JS bundle is not the source of truth.
• Keep the homepage static/lightweight. Do not require a full catalog download, SPA framework, or heavy browser i18n runtime merely to render localized copy.
• A build/publish step may consume a pinned immutable translation-resource export, or the page may use a narrowly cached screen-key response, provided provenance/version is explicit and offline/degraded behavior is defined.
• Keep ontology labels separate from UI translation resources.
• Preserve current security/CSP/GitHub Pages publication constraints and rel="noopener noreferrer" behavior.
• Do not copy source from a mutable sibling branch/head or query another service database directly.

Required contract

1. Define stable screen/resource keys for all homepage copy and accessibility-only text.
2. Provide KO/EN/JA/ZH/VI/ES/DE/FR resources from one released, versioned owner contract; record source version/provenance in the generated/published artifact.
3. Replace i18n.js message literals as translation authority. Generated/cache material may exist only as a derived artifact with a reproducible source version.
4. Keep page startup bounded: fetch/render only keys required by the current screen, with deterministic cache/fallback behavior and no full-catalog prerequisite.
5. Validate CJK wrapping/font fallback, German/Spanish/French text expansion, Vietnamese diacritics, keyboard navigation, accessible names/descriptions, normal/loading/error/degraded states, and mobile/intermediate/desktop widths.
6. Add exact-head tests that fail when a supported locale is missing a required screen key or when a published artifact cannot be traced to the translation-resource version.
7. Publish the resulting GitHub Pages artifact and verify the public deployment, not only a local build.

Acceptance evidence

• owner/released contract identifier and immutable version;
• screen-key schema and fallback policy;
• exact website head consuming that version;
• locale-completeness test for all eight locales;
• rendered/browser accessibility evidence for representative normal and failure states;
• GitHub Pages deployment URL/run tied to the exact source head;
• rollback path to the previous immutable resource version.

Do not close this issue because a single PR adds more literals to i18n.js; closure requires the released resource boundary plus consumer migration and published evidence.