[BUG] Overlaying Mac OS pills makes window moving by itself

[tiaxter]

version: 0.4.9.5
how to reproduct (this case):

1. Add multiple keyboard layout
2. Set "Caps Lock" key to switch between layouts
3. Open Ghostty
4. Presso "Caps Lock" key

bug.webm

Also when I was trying to record the screen and I wrongly selected the Ghostty window and not the fullscreen I saw the 'recording' pill at the right of the Ghostty window and not overlaying on the window

[biswadip-paul]

I investigated this and believe the root cause is one of two mechanisms:

Theory 1: Focus churn from system overlay activation
When switching keyboard layouts (Caps Lock), the TextInputMenuAgent process may briefly activate, triggering OmniWM's handleAppActivation → handleMissingFocusedWindow → enterNonManagedFocus. When the original app regains focus, OmniWM re-focuses the managed window and scrolls the viewport, causing the visible "shift."

Theory 2: CGS frame events from overlay windows bypass level filtering
SkyLight.queryWindowInfo() has no window level filtering (accepts any level), unlike getDisplayWindows() which filters to levels 0, 3, 8. System overlay pills render at high window levels (103+). If the pill generates a windowMoved/windowResized CGS event, handleFrameChanged → resolveWindowInfo → queryWindowInfo could resolve it incorrectly and trigger a relayout of the managed window beneath.

The screen recording pill mentioned in the issue would follow the same pattern — any transient system overlay appearing on top of a managed window could trigger this.

I wasn't able to reproduce this locally to confirm which mechanism is the actual cause. Happy to submit a fix if the maintainer can confirm which path is firing.