Focus goes to wrong window when transient dialog window (Handy overlay) appears/disappears

## Description When using [Handy](https://apps.apple.com/app/handy-clipboard-history/id6504770528) (a clipboard manager), its small transient overlay window (172x36px, titled "Recording") appears briefly at the bottom of the screen when holding a hotkey. When this overlay disappears, focus goes to an arbitrary window instead of the previously focused window. AeroSpace correctly classifies this overlay as a `dialog` (see AX dump below), but the focus race condition with macOS still results in the wrong window being focused. ## Steps to reproduce 1. Have multiple windows on a workspace (e.g. WezTerm, Emacs, Slack, Superhuman) 2. Focus WezTerm 3. Trigger Handy's overlay (hold the configured hotkey) 4. Release the hotkey (overlay dismisses) 5. Focus jumps to a random window (e.g. Superhuman) instead of WezTerm ## Environment - AeroSpace: 0.20.2-Beta - macOS: 15.7.3 (Build 24G419) - Handy: 0.8.2 ## AX dump of the overlay window (3116) The overlay has: - No buttons (AXCloseButton, AXFullScreenButton, AXMinimizeButton, AXZoomButton all null) - `AXSubrole: AXDialog` - `AXFocused: 0`, `AXMain: 0` - `Aero.AxUiElementWindowType: dialog` - `Aero.windowLevel: 25` (not normalWindow) - Size: 172x36 <details> <summary>Full AX dump</summary> ```json { "AXActivationPoint": "x:-1.000000 y:957.000000", "AXCancelButton": null, "AXCloseButton": null, "AXDefaultButton": null, "AXFocused": 0, "AXFrame": "x:649 y:905 w:172 h:36", "AXFullScreen": 0, "AXFullScreenButton": null, "AXMain": 0, "AXMinimizeButton": null, "AXMinimized": 0, "AXModal": 0, "AXRole": "AXWindow", "AXSubrole": "AXDialog", "AXTitle": "Recording", "AXZoomButton": null, "Aero.AxUiElementWindowType": "dialog", "Aero.AxUiElementWindowType_isDialogHeuristic": true, "Aero.windowLevel": 25 } ``` </details> ## Notes - The overlay is correctly classified as a dialog by AeroSpace - The overlay is never focused (`AXFocused: 0`) and has a non-normal window level (25) - Despite being a dialog, its appearance/disappearance triggers the macOS focus race condition described in #1097 - The fix from #1560 (ignore focus changes from popups) doesn't help here since the overlay is classified as a dialog, not a popup - Since this window is never focused and has a non-normal window level, AeroSpace could potentially ignore focus events associated with it entirely ## Related issues - #1097 — Focus race condition with macOS - #1086 — Focus previous window after closing child - #1560 — Treat popups and ignore their focus changes - #776 — Emacs child frame focus jumping