[Bug] macOS: keybindings are blocked while Excel owns Secure Input

Describe the bug

On macOS, GlazeWM keybindings stop being intercepted while Microsoft Excel owns macOS Secure Input. The keystrokes instead reach Excel as normal Option-key input (for example, alt+shift+o inserts Ø) and GlazeWM does not execute the configured command.

GlazeWM continues running and managing windows during this time. Accessibility permission remains enabled, and GlazeWM continues receiving window/focus events. Quitting Excel releases Secure Input and restores the keybindings.

Steps to reproduce

1. Run GlazeWM on macOS with a binding such as:

   yaml复制

   - commands: ['move --direction right']
     bindings: ['alt+shift+o']

2. Open Microsoft Excel and reach a state where Excel owns macOS Secure Input.

3. Focus an Excel window.

4. Press alt+shift+o.

Expected behavior

GlazeWM moves the focused Excel window to the right. If macOS makes interception impossible while Secure Input is active, GlazeWM should detect the disabled/blocked event tap and surface a clear warning or diagnostic rather than silently allowing the shortcut to type into the application.

Actual behavior

The Excel window does not move and Ø is inserted into the focused input context. Other Option-based GlazeWM bindings similarly produce symbols. Quitting Excel releases Secure Input and the same bindings work again.

Diagnostics

While the issue is present, IOHIDSystem reports that Secure Input is owned by Microsoft Excel. GlazeWM remains running and its logs continue to show window-title and focus events. There are no current Accessibility-permission errors.

Environment

• macOS
• Microsoft Excel
• GlazeWM macOS build
• Keyboard layout: U.S.
• GlazeWM Accessibility permission: enabled

Additional context

This appears distinct from #1419: that issue concerns an event tap that remains disabled after sleep/wake. Here, the failure is scoped to another application owning Secure Input and recovers when that application exits/releases it.