Design localization support for automation interface manifest copy

Context

OpenHands/OpenHands#16222 makes Canvas automation UI copy (navigation labels, list/detail/edit titles, field labels and help) come from AUTOMATION_INTERFACE in this repository. The production manifest currently supplies English literals. Once published, those literals override Canvas t(...) calls and regress the existing localized UI to English.

Problem

The interface manifest needs to describe automation-owned copy without taking locale selection away from the host application. The current literal-string contract cannot represent that safely.

Desired outcome

Agree on a versioned manifest-copy design that:

• preserves host locale selection and existing Canvas translations where available;
• lets extensions own new or automation-specific copy without coupling Canvas rendering to a particular domain;
• has a clear default/fallback locale;
• has an admission/compatibility strategy for old manifests and hosts; and
• can be tested with at least one non-English locale in Canvas.

Design directions to evaluate

1. Stable translation message IDs, resolved by the host with a fallback supplied by the manifest.
2. Locale maps in the manifest, with a well-defined fallback-chain and validation rules.
3. Manifest literals as default-language fallback only, while the host keeps its translated values for known UI concepts.

This needs a cross-repository design before enabling manifest literals as authoritative UI copy. See OpenHands/OpenHands#16222 for the consumer implementation and review context.

Start with the AUTOMATION_INTERFACE context and read OpenHands/OpenHands#16222 for the consumer implementation and review discussion. Compare the three manifest-copy designs, then document a versioned choice covering locale fallback, host and extension ownership, old-manifest compatibility, and a non-English Canvas test plan. Done means the cross-repository design is agreed before literals become authoritative.