fix(tabs): answer accessibility hit tests from the strip's own subviews

[datlechin]

#2576 diagnosed this correctly and did not fix it. The UI suite failed again on the same six cases with the same message.

What #2576 got right, and what it missed

EditorTabInteractionView.hitTest claims the tab track so the pointer has a single owner. Accessibility resolves through that same method, so the claim answered "the strip" for every tab and the strip publishes nothing: VoiceOver, Switch Control, Voice Control and XCUITest all lost the tabs together.

#2576 lifted the claim for the length of an accessibilityHitTest and deferred to super. That does not descend: NSView's implementation will not walk into subviews from a receiver that is not itself an accessibility element, and this view answers false to isAccessibilityElement. So it returned the same nothing, and CI failed identically.

The subviews are now asked directly. The point arrives in screen coordinates and is handed on unchanged, which is what they expect too.

Verification

CI is the check. The six cases are not quarantined, so a green UI suite here is the proof, and QueryInsightsTabUITests in particular predates all of this work and was green until #2571.

TableProUITests does not run on this machine at all, at clean main as much as on a branch, and a standalone harness cannot answer the question either: SwiftUI builds no accessibility tree until a client attaches, so a probe measures nothing. That is why this took two attempts.

If this run is still red, the next step is not another patch here. It is to stop resolving the pointer through hitTest at all and intercept the press in EditorWindow.sendEvent(_:) instead, which leaves hit testing, and therefore the accessibility tree, completely untouched.

• build PASS.
• swiftlint lint --strict clean.

https://claude.ai/code/session_01L7uaHbJBPV1LaWL5QXzxyp

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.