## Summary Implement `ConductorAdapter.FindInteractables()` by leveraging the conductor module's aria snapshot capability. The aria snapshot provides a semantically rich accessibility tree with pre-computed visibility, pointer-event reception, and stable element references — replacing the need for raw DOM-walking interactable detection. ## Background `FindInteractables()` in `scanner/browser/conductor_adapter.go` is currently a stub returning `nil`. The crawler relies on this method to discover DOM elements with JS event listeners so the scanner can test interactions on them. The conductor module already has a mature aria snapshot subsystem (`conductor/pkg/aria/`) that provides exactly what we need. ## Design See `PLAN_ARIA.md` in the browserker repository for the full design document. ### Key Decisions 1. **Use `ModeAI` with stable refs** — persistent `Tracker` on the adapter enables future ref-based actions 2. **Skip event listener queries for inherently clickable roles** — synthesize implicit click events for buttons, links, tabs, etc. 3. **Cursor-pointer heuristic** — elements with `cursor: pointer` are clickable only if they also have JS event listeners 4. **Reuse `HTMLElement`** — add option functions rather than creating a new type, ensuring compatibility with `ElementDiffer`/`ElementMatcher` ### Architecture ``` aria.Build(ctx, page, tracker, ModeAI) -> aria.Snapshot -> Filter: interactable roles + event listener check -> HTMLElement construction via existing option functions -> []browserk.Element returned to crawler ``` ## Implementation Order Child issues are ordered by dependency. Each issue blocks the next. ## Exit Criteria - `FindInteractables()` returns semantically correct interactable elements from aria snapshots - All existing crawler/scanner tests pass (no regressions) - New unit tests cover role mapping, tree walking, element construction - Integration tests verify end-to-end behavior with a real browser - Performance is comparable to DOM-walking approach (~53 CDP calls for 50 candidates)