[🐞 BUG] keyboard shortcut UI doesn't render `§`/`±` key

[shhac]

Describe the bug
If you assign a hotkey to use the section sign/plus-minus key, then the UI will show the selected hotkey as an empty box, or a modifier plus end of input.

On an Apple UK keyboard layout, this key is located On the left edge of the keyboard between the esc and tab keys, to the left of key 1.

To Reproduce
Steps to reproduce the behavior:

1. Go to: Preferences > Global Hotkey.
2. Click on Change for any of the hotkeys.
3. Press the section sign key, with or without any modifier keys.
4. Witness the UI showing currently selected hotkey become a blank box or the modifier key without the section sign key.

Expected behavior
The currently selected hotkey UI should show the section sign symbol along with any modifier.

Screenshots

Environment:

• macOS Version: Tahoe 26.2 (25C56)
• App Version: 1..5.5 (1) - also previous version
• Architecture: Apple Silicon

Additional context
I'm in the UK, this laptop has the Apple UK keyboard layout

Crash Logs
N/A

[altic-dev]

I cannot see them in my keeyboard or how to enable them, so cannot reproduce it unfortunately.

[shhac]

On MacOS you can change layouts via

System Settings > Keyboard > Text Input > Input Sources, click Edit, add "British" or "British - PC,"

Though I'm not quite sure if this will let you reproduce as there are some differences in the number of and positioning of the physical keys too

[altic-dev]

If you or someone wants to take this and send in a fix, happy to merge it. I am not able to work on this as I cannot reproduce the key combo etc. Thanks!

[shhac]

Fix submitted in #258.

The root cause: the app had a hardcoded table mapping key codes to US keyboard characters. Key code 10 (the §/± key on British keyboards) was missing entirely, and the fallback converted the raw number to a Unicode character — key code 10 becomes a line feed control character, which is invisible.

Beyond the reported key, the same table was also wrong for other non-US layouts (e.g. German, French) where punctuation keys produce different characters than on a US keyboard.

The fix replaces the hardcoded character table with a layout-aware lookup that asks macOS what each key actually produces on the user's current keyboard. Semantic key names (Return, Tab, Space, etc.) are still hardcoded since the name is more useful than the character. A US QWERTY fallback is kept for edge cases where layout data isn't available.