hammerspoon: mask modifiers before launching apps

[mfkd]

Summary

• keep the existing Caps Lock Hyper chord as Control+Option+Command+Shift
• post synthetic key-up events for held startup modifiers before launching/focusing apps
• preserve immediate key-down app launching without the latency from waiting for physical key release

Notes

This supersedes #4. PR #4 avoids startup modifier leakage by waiting until the physical modifiers are released, but that adds perceived launch latency. This PR masks the modifiers immediately instead.

Test

• luac -p .hammerspoon/init.lua

[mfkd]

Code review findings:

• High: .hammerspoon/init.lua:43 clears the same modifiers that define the Caps Lock Hyper chord while that chord is still physically held. After one launcher fires, macOS may consider ctrl/alt/cmd/shift released, so holding Caps and pressing another launcher key can fail or send the next key unmodified into the active app. I would not merge this as-is.
• Medium: .hammerspoon/init.lua:36 posts synthetic key-up events globally before the launcher logic knows whether it is actually launching, focusing, or toggling back. The current frontmost app can observe modifier releases, which can disrupt selection, menus, drags, terminal/editor modifier modes, or other in-progress interactions.
• Low/Medium: .hammerspoon/init.lua:29 treats modifiers generically as ctrl/alt/cmd/shift. Hammerspoon’s newKeyEvent docs note the shortcut approach is limited to left-side modifiers, so a Caps Hyper remap using right-side modifiers may not be masked correctly.

Static checks passed (luac -p, git diff --check), but I could not validate the runtime event-state behavior in Hammerspoon/macOS. The safer zero-latency direction is to avoid using real macOS startup modifiers for launcher hotkeys and instead move the launcher layer off the modifier chord.