fix(macos): map KEY_HANGEUL to Control-Space

[mrcha033]

Summary

• intercept Linux KEY_HANGEUL before the generic evdev-to-macOS keycode mapping, where LANG1 currently becomes unsupported macOS keycode 0xffff
• post the complete macOS Control down -> Space down/up -> Control up chord once on the initial key press
• suppress repeat and release events for the language key, and build the entire chord before posting so a creation failure cannot leave a key held
• restore the previously tracked modifier flags on the final Control release

Validation

• cargo fmt --all -- --check
• cargo test --workspace --all-features --locked
• cargo clippy -p input-emulation --all-targets --all-features --locked -- -D warnings
• live CoreGraphics check on macOS using the same CombinedSessionState source and HID event tap: the exact four-event chord switched ABC -> 2-Set Hangul -> ABC

Scope and limitations

This is the Linux/Arch-to-macOS emulation path only. It intentionally does not remap macOS Control-Space on capture toward Linux.

The behavior follows the macOS "Select the previous input source" shortcut. If Control-Space is disabled or remapped, or if more than two keyboard input sources are enabled, the result may not be a direct Korean/Latin toggle. The live check used the default enabled Control-Space shortcut with ABC and 2-Set Hangul. Pre-held modifier combinations remain outside the verified live scope.