Symmetric translation: component instance version updates must propagate to all translations
### Overview
When a code component's props or slots change, Canvas's `ComponentInstanceUpdater` automatically reconciles existing component instances to the new version — removing orphaned props, injecting defaults for new required props, and removing children in deleted slots. This reconciliation currently only affects the language that happens to be loaded when the entity is opened for editing.
In symmetric translation mode, `component_version` lives in the shared `tree` column group, so updating the version for one language inadvertently marks all translations as up-to-date. When a translation is subsequently loaded, `isUpdateNeeded()` sees the version already matches and skips reconciliation entirely — leaving translated inputs with orphaned prop data for deleted props and missing defaults for new props.
For config entities (ContentTemplates, PageRegions), the mechanism differs but the outcome is similar: `updateComponentInstances()` runs on the base config, but language config overrides retain stale input keys for props that no longer exist.
### Proposed resolution
Extend the component instance update pipeline to be translation-aware. When an update is performed on any language, propagate input reconciliation to all other translations of the host entity:
- A shared `TranslatableComponentTreeEntityInterface` (extending `ComponentTreeEntityInterface`) provides a single code path for iterating over translations regardless of entity type. Both `Page` (content entities) and `ComponentTreeConfigEntityBase` (config entities) implement it.
- A `TranslationInputReconciler` service encapsulates the reconciliation rules: remove inputs for deleted props, add example/fallback values for new props, preserve existing translated values for unchanged props.
- A `TranslationUpdateScopeInterface` strategy controls what gets propagated per translation (inputs only for symmetric mode), designed to support future asymmetric translation without refactoring the pipeline.
- Per-language auto-saves are created for each modified translation. If a translation already has an auto-save (from editor activity), reconciliation is applied on top of it.
Any language — including a non-default language preview — can trigger the update and propagation to all other translations.
Fixing update problems that exist outside of translation (i.e., that also affect the default language) is out of scope; those should be filed as separate issues.
### Acceptance criteria
| # | Criteria |
|---|---------|
| 1 | When a new optional prop is added to a code component, all translated instances gain the new prop with the same fallback/example value used for the default language instance. |
| 2 | When a new required prop is added, all translated instances receive the example value as the fallback. |
| 3 | When a prop is deleted, the prop data is cleaned up from all translated instances when loaded for editing. Rendering ignores the deleted prop across all languages. |
| 4 | When a slot is deleted, the slot and its nested content are removed from all translated instances upon loading for editing. Rendering ignores the deleted slot across all translations. |
| 5 | When a new slot is added, all translated instances reflect the new slot, allowing editors to populate translation-specific content. |
| 6 | When a prop type is changed (unsafe), the update is blocked for all languages consistently. |
| 7 | Existing translated string values (plain text, HTML, URLs) for unchanged props/slots are preserved and not overwritten. |
| 8 | The Canvas preview (language dropdown from #3585452) correctly renders the translated page with the updated component structure. |
| 9 | The update propagation does not require editors to manually re-translate unchanged content. |
| 10 | No orphaned translation data remains after prop/slot deletion. |
### UI changes
None in this issue.
issue