fix(native): restore getByRole through Chrome's accessibility tree

[cooleryu]

Summary

Fixes #1325.

getbyrole now resolves roles through Chrome's accessibility tree instead of approximating ARIA roles with DOM selectors. This restores support for implicit roles such as <a href> -> link and <h1> -> heading, and avoids confusing <link rel="stylesheet"> with an interactive link.

Root Cause

PR #1153 brought handle_getbyrole back to a selector-based path:

document.querySelectorAll('[role="{role}"], {role}')

That only works for explicit [role=...] or tag names that happen to match the role. It misses browser-computed roles, which is exactly what getByRole is meant to use.

Changes

• Query Accessibility.getFullAXTree for getbyrole.
• Match role, accessible name, and exact against Chrome's computed AX role data.
• Register the matched backend DOM node as a temporary ref and run the requested subaction through the existing interaction path.
• Continue past matching AX nodes without backendDOMNodeId, so a virtual AX node does not block a later actionable DOM-backed match.
• Add unit coverage for exact/partial matching, ignored nodes, virtual AX nodes, and generic implicit roles.
• Add an ignored e2e regression test covering a page with both <link rel="stylesheet"> and a clickable <a> link, plus an implicit heading role.

Test Plan

• cargo fmt --manifest-path cli/Cargo.toml -- --check
• cargo test native::actions::tests --manifest-path cli/Cargo.toml
• cargo test e2e_getbyrole_uses_accessibility_tree_for_implicit_roles --manifest-path cli/Cargo.toml -- --ignored --test-threads=1

Risk

The main behavior change is that getbyrole now trusts Chrome's AX tree instead of a hand-rolled DOM selector. That should be closer to user-visible accessibility semantics, but it may expose different matching order where the previous selector approximation happened to find a DOM node first.

[vercel]

@cooleryu is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.