text-overflow: ellipsis: implement in Blitz paint, or in Parley?

`text-overflow: ellipsis` (and the string form) is parsed by Stylo but has no
effect in Blitz today: overflowing lines in a clipping inline root are simply
clipped.

I have a working implementation and would like to know where you want it
before opening a PR, because there are two reasonable homes for it.

### Option A — paint-time truncation in Blitz (what I have)

- `blitz-dom` records the marker on the inline root's `TextLayout` when style
asks for one (`overflow` other than `visible` + `text-overflow`): `None` for
`clip`, `"…"` for `ellipsis`, the given string otherwise. One value applies
to the inline-end side; two values name start then end.
- `blitz-paint::text::stroke_text` gets an optional `TextOverflowClip`
(content-box width + marker). For each line wider than the content box,
glyphs ending past `max_width - marker_advance` are dropped and the marker is
drawn once after the kept glyphs, with the first run's font/size/colour
(looked up through `skrifa` charmap + metrics; fonts without U+2026 fall
back to `...`).
- Layout, selection and hit testing keep the full text, as the spec describes
(the ellipsis is a rendering effect).

Pros: self-contained in Blitz, no Parley API change, ~150 lines.
Cons: decorations (underline) are still drawn full-width; the marker is
shaped outside Parley; only the inline-end side is handled (no RTL/start
marker); other Parley users don't benefit.

### Option B — truncation as a Parley layout feature

Parley would expose something like `Layout::truncate_lines(max_width,
marker)` (or a `LineBreaker` option) that rewrites the overflowing line's runs
and shapes the marker in the right font, so decorations, selection geometry
and bidi come out right by construction. Blitz would only pass the option.

Pros: correct for all consumers, RTL and decorations handled once.
Cons: a Parley change first, larger scope.

### Question

Would you take Option A now as an interim (with the limitations listed and
tracked), or would you rather see this land in Parley first? If the latter,
I'm happy to open the Parley issue/PR with the same design and keep the
Blitz side to the `TextLayout::text_overflow` plumbing.

WPT dirs to measure either way: `css/css-overflow/text-overflow-*`,
`css/css-ui/text-overflow-*`.

Start by reviewing the proposed Blitz path in blitz-dom and blitz-paint::text::stroke_text, then compare it with the suggested Parley Layout::truncate_lines design. Use the WPT directories css/css-overflow/text-overflow-* and css/css-ui/text-overflow-* to assess expected behavior. Done means the project chooses an implementation home and defines the corresponding scope and tests.

Written by the indexing model from the issue text.