fix(cua-driver): match localized macOS Chrome consent dialogs

[enderzcx]

Summary

• Problem this solves: macOS existing-profile attachment recognizes Chrome's browser-owned remote-debugging consent sheet from English text, so a valid localized sheet can remain visible while browser_prepare fails with browser_wrong_target_refused.
• What changed: keep the existing English semantic matcher, then use a language-independent structural fallback that requires one exact AXSheet, a heading bound to the sheet title, two explanatory text nodes, and exactly three pressable buttons forming one unambiguous AppKit dialog row. The outer standard action is selected as Allow and the adjacent standard action as Cancel, including mirrored RTL layouts. Ambiguous or incomplete sheets still fail closed.

The driver and public browser guidance now distinguish localized setup-page limitations from the native consent dialog, which no longer depends on button text on macOS.

Related work

Refs #2892

RFC: not required; this preserves the existing MCP, permission, and exact-window contracts and changes only the macOS platform matcher.

Compatibility and risk

• User-visible, API/CLI/MCP, migration, permission, or platform impact: macOS Chrome/Edge consent dialogs can be accepted when their UI is localized. There is no API, CLI, MCP schema, permission-mode, or migration change. Localized controls on the internal setup page remain outside this change.
• Risk and rollback: the structural fallback is constrained to the exact approved Chromium process and sheet. It requires a title/heading binding, two explanatory text nodes, three distinct in-sheet AXPress buttons, and a unique separated standard pair. Any geometry or cardinality ambiguity returns browser_wrong_target_refused. Rollback is the single commit in this PR.

Validation

• Focused tests and checks:
  • cargo test -p platform-macos browser::consent_ui::tests --lib --locked (7 passed)
  • cargo test -p platform-macos --lib --locked (347 passed, 2 ignored environment tests)
  • cargo fmt --all -- --check
  • cargo clippy -p platform-macos --lib --locked --no-deps -- -D warnings with only pre-existing crate lint categories allowed (passed; the unfiltered command currently fails in unrelated existing modules)
  • Cua Driver documentation generator drift check (passed)
  • public docs hygiene check (passed)
  • git diff --check
• Manual or platform evidence: reproduced with Chrome 148 on macOS using a Simplified Chinese consent sheet. The live AX structure exposed one bound sheet/heading, two explanatory text nodes, and the three-button AppKit layout represented by the regression fixture. No page content, profile paths, cookies, or screenshots are included.
• Known gaps or CI still required: the release-signed macOS existing-profile E2E should run in the maintainer harness. Installing a locally signed bundle would change TCC identity, so this contribution does not claim a local release-bundle E2E result.

Contributor and release checks

• The PR is focused and the description matches the final diff.
• This change does not require an RFC, or the accepted RFC is linked above.
• Tests, documentation, and platform evidence are included or the gap is explained.
• The PR title is a Conventional Commit describing the production change.
• External contributor authorship is preserved, or no external contribution is included.
• If release-tracked files changed but this is intentionally non-releasing, the no-release label is applied. (Not applicable: this is a user-visible Cua Driver fix.)