[iamnbutler]

Gap 10, route 1: desktop_select now works on text in web content (paragraphs, headings, links), which has no settable AXSelectedTextRange.

How

• New patch peekaboo-web-text-selection.patch, last in the stack (after feat: press media, volume and brightness keys as system-defined events #80's system-defined-key).
• For an element without a settable range, the patch finds its AXWebArea and reads the element's text-marker range.
• It locates the requested UTF-16 range with AXTextMarkerForIndex, starting from the element's start index.
• If that misses, it steps AXNextTextMarkerForTextMarker, capped at 2048 steps and 300 ms. Past the cap, the request is refused before anything is selected.
• A candidate counts only when the strings before, inside and after it match the requested offsets.
• It sets AXSelectedTextMarkerRange on the web area, then polls the readback for up to 1 s.
  • completed only when the selection reads back to exactly that range.
  • Otherwise unknown (indeterminate).
  • An existing exact selection is a confirmed no-change.
• The client and bridge are unchanged; the existing selection receipt still applies.

Docs

• Updates the desktop_select description and the tools.md section.
• Adds a "Copy text from a web page" recipe (select, Command-C, clipboard read).
• Route 2 (selectable native text that isn't a field) and PDF text in Preview are documented as unverified.

Tests

• swift test --filter ActionInputDriverTests: 93 passed, including the new cases:
  • index route
  • skewed index falling back to stepping
  • step cap refused with nothing selected
  • caret placement
  • existing selection
  • readback elsewhere → unknown
• npm test passes and npm run check is clean. The native build with the full patch stack passes.

Live checks: pending, screen locked. Tracked in #42:

• Safari paragraph
• Chrome paragraph
• a link
• a long page that hits the step cap
• route 2
• Preview PDF