[iamnbutler]

Fixes #195

Root cause. WebKit's AXPress on an ARIA menu item, button, tab, toggle or list item presses the first native <button>/<select>/checkbox inside it (WebCore AccessibilityNodeObject::actionElement → nativeActionElement). Ace's project rows are Base UI role="menuitem" divs with a hover-only <button aria-label="Remove …"> inside, so a point click on the row (which hit-tests to the AXMenuItem and presses it) pressed Remove.

Fix (DesktopMac/Pointer.swift, pressNestedSafely): before pressing a WebKit web element in those roles that holds a button/pop-up/checkbox/radio descendant, the host

• checks that Accessibility finds the element itself at the click point (WebKit frames for these rows can be wrong, e.g. 70 pt tall rows), else refuses;
• sends a real left click routed to the exact window at the point when that window is the key window of the active app (WebKit drops the first click into a non-key window), else refuses, naming the nested control.

Every AX press result now carries pressed: {role, label}; the guarded route adds nested_control and a note. Chromium apps are excluded (Chromium presses the node itself).

Checked. Reproduced with a WKWebView fixture running Base UI 1.3 Menu + Tooltip in Ace's row markup, through the standalone host: before, a point click on the "desktop-tools" row logged REMOVE desktop-tools; after, the click is refused with the message naming "Remove desktop-tools" (fixture app inactive), an element-ID click is refused (center lands off the row), a point click on the remove button itself presses it and says pressed: AXButton "Remove desktop-tools", and the menu trigger still presses normally. Routed events reach the page (a routed double click selected the row). Not verified on an active WebKit window, since that would take keyboard focus. Unit tests in PressRedirectTests; swift test passes.