🐞 Fix stale isLoopOpen check causing action keys to leak to focused app

[bit-saver]

Summary

In KeybindTrigger.performKeybind, the normal (non-bypassed) keybind branch returns its consume/opening decision based on the isLoopOpen value captured at the top of the function — i.e. before openLoop() ran. When Loop's open-state hasn't propagated by the moment that stale value is read (easy to lose when the trigger key and action key are pressed in rapid succession), the function returns .opening and the caller forwards the action key to the frontmost app.

The symmetric bypassed-action branch 16 lines below already uses checkIfLoopOpen() (fresh check) for the same return decision, and the inline comment immediately above the affected line documents the intent:

Only consume the event if the last command actually opened Loop.

The stale check contradicts that comment; the fresh check honors it. This appears to be an oversight in the non-bypassed branch.

Change

One line in Loop/Core/Observers/KeybindTrigger.swift:

-                    return isLoopOpen ? .consume : .opening
+                    return checkIfLoopOpen() ? .consume : .opening

Symptom this fixes

When holding the trigger key and pressing an action key (e.g. Globe + W bound to Maximize), the action runs but the action key also reaches the focused app, triggering unwanted typing or app shortcuts. Reproducible on macOS 26.3 against the current develop branch.

Verification

With the patch applied, action chords cleanly resize the window without leaking the action key. Bypassed actions continue to work as before (they already used the fresh check). No other behavior change.

I'm running a locally built copy of develop with this single-line fix and have verified the leak is gone in TextEdit and a few other apps.

[mrkai77]

Thank you! For future PRs, please use our PR template instead of creating your own. Since this is a relatively small change, though, I’ll go ahead and merge it :)