[adm 11] Integrate `expo-localization` through the module-owned administration strategy

[artiphishle]

Roadmap: #115

Respect the roadmap first and the AGENTS.md file of every repository touched.

Previous roadmap step

[adm 10] (#125) establishes /ankh/modules, canonical module lifecycle ownership and a module-owned admin/config contribution contract. This issue proves that architecture with the existing expo-localization module rather than rebuilding Localization as Studio-specific code.

Repository impact

Likely:

• ankhorage/studio
• ankhorage/orchestrator
• ankhorage/orchestrator-module-expo-localization
• runtime/localization integration packages only if current canonical ownership requires them

Pause at package release boundaries per roadmap rule #6.

Goal

Restore first-class localization authoring through the module-owned strategy from [adm 10], with the localization domain remaining reusable independently of Studio.

The canonical administration route should be contributed/hosted under the module namespace, conceptually:

/ankh/modules/expo-localization

Use the actual canonical module ID from the current module package.

Do not create a separate top-level /ankh/localization route.

Historical capability reference

The late ankhorage4 LocalizationPanel supported, among other things:

• locale/default-locale management;
• dictionary loading/saving;
• scanning component metadata for translatable fields;
• missing-translation filtering/search;
• linking text fields to translation keys;
• updating localization module configuration.

Restore the useful product capabilities, but do not copy the panel architecture or keep localization domain logic in Studio.

Ownership target

expo-localization module
  -> canonical localization configuration/domain state
  -> locale/default locale rules
  -> translation resource/status model
  -> module-specific admin contribution
  -> update/reconfigure behavior

Orchestrator
  -> lifecycle / ledger / canonical module update semantics

Studio
  -> hosts contributed module admin route
  -> supplies project/manifest/component metadata context through generic contracts

Investigate the best canonical source of truth for localization state. If the module ledger owns configuration, changes must update through that contract and deterministically synchronize generated i18n resources/config/files as required.

Do not create competing Studio state plus generated-file state plus ledger state without an explicit canonical owner.

Requirements

• manage configured locales;
• manage default locale;
• view/edit translation resources/dictionaries through module-owned APIs;
• scan current manifest/component metadata for translatable fields using injected metadata/context rather than importing Studio-specific component knowledge into the module;
• identify missing translations;
• support useful search/filtering;
• link eligible manifest content to translation keys where current contracts support it;
• synchronize module configuration/resources deterministically;
• retain standalone module usability outside Studio.

The exact i18n implementation/resource format must be derived from the current module/runtime integration, not assumed from the old panel.

Likely files

Studio, non-exhaustive:

src/ui/admin/*
src/host/orchestrator/*
src/core/StudioProvider.ts

Module/orchestrator files must be identified from current repositories. Historical LocalizationPanel.tsx is behavioral reference only.

Phases

Phase 1 — localization source-of-truth/update contract

Determine and implement canonical module-owned localization state and reconfiguration/update behavior.

Phase 2 — module admin contribution

Implement localization administration in/contributed by the module package under the [adm 10] contract.

Phase 3 — Studio integration and migration hardening

Host the contribution at the module route, remove any remaining Studio-specific localization implementation and validate generated resources.

Tests

Cover at minimum:

• add/remove locale;
• default-locale validity;
• translation resource updates;
• missing-translation derivation;
• translatable-field scanning from injected metadata/context;
• link-to-translation-key mutation where supported;
• module config/ledger/resource synchronization;
• standalone module contract does not depend on Studio internals;
• module route contribution resolves through generic [adm 10] hosting.

Acceptance criteria

1. Localization administration lives under /ankh/modules/{expo-localization-id}.
2. No separate /ankh/localization area is introduced.
3. Localization domain/config/update logic is module-owned as far as practical.
4. One canonical localization source of truth is defined and documented.
5. Locale/default-locale and translation-resource management work.
6. Missing translations/translatable fields are surfaced usefully.
7. Generated i18n config/resources synchronize deterministically.
8. The module remains usable independently of Studio.
9. Studio does not contain hardcoded localization-domain UI logic beyond generic hosting/context integration.
10. Behavior-focused tests and full validation pass.
11. No legacy/compatibility/ankhorage4 dependency is introduced.