Defensively normalize translated text synthesis in admin

[tazzytazzy]

Problem Statement

TranslatedTextSynth was still using fragile behavior when Lunar\FieldTypes\TranslatedText crossed a Livewire boundary directly.

In the old behavior:

• dehydrate() returned nested Text objects instead of plain locale strings
• get() used direct property access that does not match how TranslatedText stores locale values
• set() assumed the locale field already existed, which could fail when writing a new locale value

This was not the root fix for the main product rich-text issue #2445 , but it left the synthesizer inconsistent and brittle.

What Changed

• Updated packages/admin/src/Support/Synthesizers/TranslatedTextSynth.php
• dehydrate() now returns plain locale string values
• get() now reads the locale value from the underlying translated collection
• set() now initializes a missing Text field before writing to it
• Kept TipTap document array handling so rich editor payloads are converted to HTML before storage
• Added package coverage in tests/admin/Unit/Livewire/Synthesizers/TranslatedTextSynthTest.php

Result

The translated text synthesizer now behaves safely and consistently if a TranslatedText field is hydrated, accessed, or mutated directly through Livewire.

This is a defensive correctness patch and is intentionally separate from the main AttributeData fix.

Code Generation Source
Codex 5.4 on Extra reasoning settings. I have also personally tested the results within the Lunar admin panel, and the patch is working as expected. This PR was split up from #2445 for separation of concerns/attribution.

[alecritson]

Can we just remove commented out code :)