feat(text): let text declare that it must fit its box

[LeadcodeDev]

Closes the second Critical gap from the re-scored Remotion differential — and the one the original audit called the most profitable reliability lever on this project. With #169 merged, both Critical gaps are now closed.

Why this is worth more than its size

Until now, a text that overflowed its box was reported and nothing more. apply_fixes deliberately refuses ContentOverflowsBox, and its comment says why:

growing the box/card, shrinking the font, or shortening the copy are all legitimate fixes … not ours to pick

That reasoning is correct only while the engine has no way to shrink text at all. Given one, the arbitration disappears: the author declares the intent ("this text must fit here"), and a whole class of generation failure stops existing. The value is not the measuring function — it is the removal of a failure class.

What this adds

style.text-autofit makes text and gradient_text reduce their font size until they fit the resolved width and, where taffy defines one, the content-box height.

$ rustmotion validate -f overflowing.json
ERROR: text (wrapped content exceeds its own box)
  hint: text wraps to 343px tall at this width but its box is only 80px tall

# same file, with "text-autofit": true
$ rustmotion validate -f overflowing.json
Valid scenario: 1 scene(s) in 1 view(s)

white-space: nowrap still decides whether the text wraps; autofit decides at what size — they compose rather than compete. auto_scroll never interacts: codeblock and terminal do not read the field, and a test pins that a declared text-autofit stays inert on components whose painters ignore it, so it cannot become a measure/paint divergence somewhere else.

rustmotion info also reports each text's natural size, through the same measurer the engine and the validator use.

The three hazards, and how each is answered

Measure and paint must agree. This repository spent a whole chantier repairing divergences where TextIntrinsic measured one thing and the painter drew another, blinding the geometry pass to real overflow. One pure resolve_text_autofit is called with identical arguments from both sides — the agreement is structural, not coincidental. The tests assert it directly rather than checking the render merely looks right.

The size must not drift. Paint runs per frame. The resolution is fed the complete content, never the typewriter-truncated view, so a reveal cannot make the size oscillate mid-read. Asserted by rendering the same content at two instants and comparing pixel grids byte for byte.

Shrinking needs a floor, or a visible defect is traded for a discreet one. The floor reuses MIN_LEGIBLE_FONT_RATIO — already calibrated by real visual inspection — relocated into rustmotion-core so both sides share one constant instead of inventing a second. At the floor, the text stops shrinking and the geometry violation is still raised: never a silence.

The floor's known limit, and what I did about it

The floor is pinned to a 1080-tall reference, because IntrinsicMeasure::measure receives no frame height and using the real one on the paint side alone would reintroduce exactly the divergence above.

On a taller canvas the pinned floor therefore sits below the legibility threshold, which is relative to the real frame. Verified: a declared 120px shrinking toward ~13px on a 2160-tall frame passed check_legibility in complete silence, because that check reads the declared size.

That is the failure mode this feature exists to remove, not relocate. check_legibility now warns in precisely that case:

Warning: views[0]…: text-autofit may shrink this text to ~13px, below the 26px
legibility floor for a 2160px-tall frame. Give it a wider or taller box so it
settles above that, or check the rendered frame.

Conditional by design — it fires only where the two constants genuinely diverge (canvases taller than 1080) and stays quiet at 1080, so it is not noise on every autofitting text in the common canvas. It says "may" because resolving the actual shrunk size needs layout, which that pass does not run.

The precise fix is a canvas-relative floor on both sides, which needs the frame height plumbed into TextIntrinsic and through box_builder. Out of scope here; worth its own change.

Recommendation on --fix, not applied

validate.rs was kept read-only on purpose: wiring an auto-fix that rewrites the user's file is a decision to take explicitly, not a side effect.

With autofit available, apply_fixes could answer ContentOverflowsBox on text/gradient_text by inserting "text-autofit": true. It is non-destructive and reversible — it alters neither declared dimensions nor content — putting it in the same risk category as the two fixes already accepted (white-space removed, auto_scroll forced), both of which also change the render. I recommend wiring it; say the word and it is a small change.

Verification

• cargo test --workspace: 25 targets, 1031 tests, 0 failures (32 new)
• cargo fmt --all --check and cargo clippy --workspace --all-targets -- -D warnings: clean
• Examples: 7 of 8 validate; the eighth is examples/ferriskey-presentation.json does not pass rustmotion validate (pre-existing on main) #157, pre-existing on main — checked that it declares no text-autofit and that the non-autofit path is unchanged

Not covered, deliberately

• caption / rich_text / codeblock / terminal do not get autofit — their painters do not consume it, and adding the field without the painter is how measure/paint divergences start.
• letter-spacing / line-height declared in absolute units scale with the shrink, where CSS would keep them fixed. Documented approximation; the common cases (unitless, %, em, or the 1.3x default) are exact.
• The height axis only engages when the box has a height taffy actually resolves.