Add a highlight prop for text search A `highlight` prop on any element paints a background wash behind matched or explicitly given text ranges. It scopes to the declaring element's subtree, so the root searches the window and a container searches that container. Nothing resolves and nothing paints unless an element declares one.
the quick brown fox


Every string GPUIX paints already funnels through `crate::text`, so one hook
there reaches ``, ``, `` and `` with no per-element
props. `useTextSearch` drives a find bar; `findRanges` is the same matcher in JS
for row data a virtual list never mounted.

There is deliberately NO joined document for a query
--------------------------------------------------

`shouldSetTextContent` is false, so React makes a separate host text node for
every interpolated string. `Hello {name}!` is three painted runs of
one logical line, and a per-node matcher cannot find `Hello Tommy`. So text has
to be merged before matching.

Merging the WHOLE subtree into one string was the obvious approach and it is
wrong: a 5k-row chat becomes one megabyte string, and the query is part of the
cache key, so a find-bar keystroke rebuilds it. Instead `GroupList::collect`
merges only what React split: adjacent primitive text children of one parent.
A match never crosses a group, which is what a browser does across a paragraph
boundary. A joined document is built only when a spec supplies explicit
`ranges`, because only then does anyone index into it.

Grouping is structural. It never reads `display`, which only knows `flex` and
`grid` here, and every text node already sits inside a `div`.

Two caches, and why search_revision exists
------------------------------------------

    GroupList   keyed by  search_revision            (walk + fold)
    MatchSet    keyed by  search_revision + matcher  (scan)
    washes      derived   colorize()                 (O(matches))

`highlight` is itself a custom prop, so `subtree_revision` moves on every
keystroke. Keying the group list on it makes the cache do nothing for the one
case it exists for. `search_revision` moves on text, structure, and a nested
declaration appearing or disappearing; not on style, not on a native element's
own props, not on the query.

`matcher_hash` excludes `activeIndex` and the colours, so moving a find cursor
only re-colours matches that were already located.

A timing budget cannot police this. On the 1000-turn chat the broken version is
2.7ms against 1.9ms, because most of that text lives in native element props
rather than retained ``. `highlight_cache_tests` in `renderer.rs` compares
`Arc` identity instead and fails outright.

Native elements match their own painted string
----------------------------------------------

``, `` and `` build text inside `render()`, so the
build-time resolver never sees it. Rather than a second traversal that
re-derives their text and `sub` values, which would drift from markdown's
render-time counter, they match the exact string they are about to paint
through `washes_for_native_run`.

Their matches share one ordinal sequence per declaration, continuing after the
retained matches via `NativeHighlight::offsets` and memoised per run so a row
gpui paints twice keeps its numbers. Numbering each run from zero made
`activeIndex: 1` mark the second match of every code line active.

Copy grouping, and destroy_element
----------------------------------

Two pre-existing bugs surfaced while building this, each with its own changeset.

`join_spans` put a newline between every span, so copying the interpolated line
above yielded `"Hello\nTommy\n!"`. Runs now carry a group and same-group runs
join with nothing. Copy and search share `search::group_id`, because deriving
one from `element.parent` and the other from adjacency silently diverges when a
non-text sibling sits between two leaves.

`destroy_element` never unlinked the child from its parent's `children` and
never called `mark_changed`. React sends `removeChild` first so it was hidden,
but the batch and napi APIs both allow a direct destroy.

Contract
--------

Matches are non-overlapping and leftmost-first. Case-insensitive matching uses
Unicode lowercasing, not full case folding, so `ﬀ` does not match `ff`; `fold`
carries an offset map because lowercasing changes byte length. Explicit ranges
are UTF-16 code units and a boundary inside a surrogate pair is rejected, never
snapped. A word boundary is any code point that is not a letter, a digit, or
`_`. `userSelect: "none"` does not opt out of search, because a browser still
finds that text; only real chrome does.

`onHighlight` is queued during build and flushed after the root build returns,
keyed on `MatchSet::identity()`. Emitting inline lets a `setState` in the
handler re-enter the build; keying on the count alone misses a query swap that
finds the same number of hits.

Testing
-------

A wash is a quad, so `getPaintedText()` cannot see it. `getPaintedHighlights()`
reports the matched range in UTF-16 units plus the boxes drawn, one per visual
row, on all three renderers including the browser build.

167 native tests, 305 react, 17 examples.

Known limits, documented rather than hidden: `onHighlight` counts retained text
only, and a `` row that was never built cannot be matched,
counted, or scrolled to. `findRanges` exists for exactly that.

Session: ses_fc21bea16ffe1AkeGWr9j3cQTa