fix: bind OEM keys by physical position, not character

[ProfetGit]

Problem

§ (the key left of 1 on FI/SE layouts) could not be bound at all — neither as a hotkey nor as the keyboard auto-press key.

Two causes:

1. Hard-coded VKs. Punctuation keys were stored as the character they produce and mapped to a fixed VK. That mapping is only correct on US layouts — on FI/SE the same physical key is § with VK_OEM_5, not ` with VK_OEM_3.
2. Byte-length check. parse_hotkey_main_key accepted single-byte tokens only, so any non-ASCII character (2 bytes in UTF-8) fell through to Couldn't recognize '§' as a valid key.

Changes

Physical key resolution. OEM/punctuation keys are stored by physical code (Backquote, Minus, Semicolon, …) rather than by the character they type, and resolved to a VK at parse time with MapVirtualKeyW(scancode, MAPVK_VSC_TO_VK_EX). Display goes through navigator.keyboard.getLayoutMap(), so the UI shows the real cap. VkKeyScanW is a fallback for layout-specific characters (§ ö ä ü ç) that arrive without a usable code.

Hold mode may reuse the hotkey as the auto-press key. The conflict guard in start_clicker_inner blocked hotkey == auto-press key to prevent the clicker retriggering its own hotkey via GetAsyncKeyState. While the low-level hooks run, press state comes from hardware events only — injected input carries AUTOCLICKER_EXTRA_INFO and is skipped — so Hold mode is exempt. Toggle mode still blocks it, where the loop is real. This is what makes "hold a key to spam that same key" possible (WoW one-button macros, etc.).

Minimum keyboard hold. With the duty cycle off, hold was 0 ms: keydown and keyup landed back-to-back. Desktop apps register that; games do not, since they sample the keyboard once per frame (~16 ms at 60 fps). Keyboard cadences at ≥50 ms interval now floor the hold at 20 ms. Faster cadences keep 0 so the batched SendInput fast path is unaffected.

Compatibility

Existing bindings keep working — character tokens (`, ;, \) still parse to their previous VKs. Word-form tokens (backquote, semicolon) now resolve physically, which changes their VK only on non-US layouts, where they were pointing at the wrong key anyway.

Testing

• cargo test — 79 passed, including new round-trip coverage for physical code tokens and VkKeyScanW resolution
• npm test — 9 passed; tsc --noEmit, eslint, cargo clippy, cargo fmt --check clean
• Verified manually on a FI layout in WoW: hold § → § spams at the configured interval into a GSE macro, release stops it

Note: injection into an elevated game window requires the clicker to be elevated too (UIPI), which is pre-existing behavior and not changed here.

No version bump or dated changelog heading — changelog entry sits under # Unreleased for you to fold into whatever release you want.

🤖 Generated with Claude Code