fix(macos): report focus within inactive windows

[steipete]

Problem

The macOS adapter uses host-gated consumer focus queries for isAccessibilityFocused and its view's focused-element query. When a host becomes inactive, those queries lose the focused element even though AppKit controls continue to expose their window-local first responder. This prevents assistive clients from reliably targeting controls in background windows.

Change

Read focus within the tree for these two macOS queries, resolve an active descendant when present, and retain the existing focusability filter. Global focus-change notifications continue to use host-focused consumer state, so background updates do not move the screen reader's global focus.

Add a native main-thread regression covering inactive/active hosts, independent windows, focus changes, active descendants and their removal/restoration, and root exclusion. The test creates hidden windows and never activates the application. Document the query/notification distinction. This ports the prepared change to the current adapters/macos layout and TreeInfo API; generated changelogs are untouched.

Verification

• cargo fmt --all -- --check
• cargo test -p accesskit_macos -p accesskit_consumer --locked: 206 consumer tests plus the native macOS focus regression passed.
• cargo clippy -p accesskit_macos -p accesskit_consumer --all-targets --locked -- -D warnings
• The same tests passed on Rust 1.87.0, the current workspace MSRV.
• The original regression failed on the unpatched published macOS adapter. Prior native notification capture of the equivalent change recorded zero global focus notifications during background phases and five in active-host positive controls. Interactive VoiceOver speech was not exercised.

The fix is limited to macOS focus queries. It does not alter consumer focus semantics or host-gated notification delivery.

AI-assisted: this change was developed with AI coding assistance (OpenAI Codex) and reviewed and tested by the author.