why

text= locator count() and nth() take seconds on large repeated lists: text matching removes ancestor matches with a pairwise contains loop, and indexed resolution re-scans the page once per index and keeps a remote handle for every preceding match.

Closes #3238

what changed

• Added a shared linear text walk (textMatches.ts) used by both countTextMatches and resolveTextSelector. Ancestors are suppressed during the walk and leaves skip layout when their text has no whitespace to collapse. nth stops early once the requested index is found.
• FrameSelectorResolver.resolveAtIndex now evaluates the selector helper once and creates one remote object, instead of going through resolveAll.
• Updated the resolution tests that assumed prefix handles, and added tests for ordering, shadow hosts, closed and nested shadow roots, hidden text, whitespace collapsing and a 10,000-row list.
• Added a changeset.

test plan

• Extension unit tests: 68 files, 1057 tests pass.
• Locator integration tests (textSelectorInnermost, locatorNth, locatorCount): 26 of 26 pass in Edge on Windows.
• Issue repro (10,000 rows): count() ~4,124 ms to ~15 ms, nth(2).innerText() ~12,498 ms to ~15 ms. The first call is ~1.25 s because of cold-start setup.

---

Summary by cubic

Speeds up text= locator count() and nth() on large repeated lists.

• Text matching now runs in a single linear walk that suppresses ancestor matches without a pairwise contains loop, and nth() stops early after finding the requested index.
• FrameSelectorResolver.resolveAtIndex now evaluates the selector helper once and returns one remote object, instead of resolving and releasing all preceding matches.
• Updated resolution tests to match the new single-evaluation behavior, and added tests for match ordering, shadow hosts and nested shadow roots, hidden text, whitespace collapsing, and a 10,000-row list.