Render: mixed-value text properties collapse to a single value

[nathanacurtis]

Found while round-tripping the typography fixtures for #260.

Symptom: a text node whose property varies across its character ranges is written as one uniform value, so the mixed state is lost.

testTypography3  variants[0].elements.text.styles.typography.letterSpacing
  baseline:    "Figma mixed"
  round-trip:  0

The reader represents a per-segment value as "Figma mixed". The writer has no way to act on that — it applies a single value to the whole node — so the round-trip reads back a uniform property.

Questions this needs answered before implementing:

• Should a spec carry per-segment ranges at all, or is "Figma mixed" deliberately lossy? The writer cannot reconstruct segments from a marker alone.
• If ranges are wanted, that is a schema addition (segment list per text property) and an ADR — the reader would need to emit getStyledTextSegments output.
• If not, the writer should at minimum skip a "Figma mixed" value rather than coercing it to a number, and the diff harness should treat it as a known-lossy marker instead of a fidelity finding.

Reach: 1 fixture in the current corpus (testTypography3), on letterSpacing. Any per-segment text property can hit it — fontSize, fontName, textDecoration, fills.

Verification: round-trip testTypography3; typography.letterSpacing must not report a fidelity difference.

Part of #208.

[nathanacurtis]

Closing in favour of #280, which covers the general problem this was a symptom of.

Investigation changed the picture. The intended contract — mixed characters derive the value from the first character — turns out to be implemented in exactly one place (FontStyle, REST path), where the derived value is computed and then discarded; present but unreachable in a second (LetterSpacingStyle, REST path, shadowed by an earlier early-return — this is what produced the testTypography3 baseline); and absent entirely in the third (MixedStyle, Plugin API, which is also generic over any mixable property, not just typography).

So this is a reader inconsistency, not a writer defect, and it carries a CLI-vs-plugin parity risk: REST can derive a first-character value from characterStyleOverrides[0], while the Plugin path has no equivalent — getStyledTextSegments/getRangeXxx appear nowhere in the reader.

The testTypography3 letterSpacing result is being ignored deliberately: a known discrepancy, not render fidelity loss. Design systems modelled so far do not mix values within a text node, so nothing here is currently biting.

Details, the three emitters with code, the latent writer-side enum coercion on textCase/textDecoration/leadingTrim, and the open decisions are all in #280.