fix: hold key continuously at 100% duty keyboard mode (#191)

[wydvoy]

Summary

Fixes #191. At 100% Click Duration in single-keyboard mode the engine was sending a KEYDOWN/KEYUP pair per cycle, which target apps see as a rapid tap rather than a held key. This PR rewires that path to a true Win32 hold:

• One initial WM_KEYDOWN (with Shift held first if uppercase is on)
• Repeated WM_KEYDOWN events per cycle — matches the Windows auto-repeat shape (keyboard input docs)
• A single WM_KEYUP on stop

The new KeyboardHold guard owns the release, so panic/early-return paths still let the key go via Drop.

The gate is intentionally narrow — input_type=keyboard, key_code set, double-click disabled, duty >= 100%. Anything else keeps the existing per-cycle behavior.

Changes

• src-tauri/src/engine/keyboard.rs — add KeyboardHold (idempotent release + Drop) and hold_key helper
• src-tauri/src/engine/worker.rs — detect the 100% keyboard-hold case, take/release the hold across batches, count repeats correctly so click_count stays consistent

Test plan

• cargo test — 39 passed (4 new keyboard-hold tests)
• cargo fmt --check
• cargo clippy --all-targets -- -D warnings
• npm run lint
• npm run frontend:build
• Manual smoke against https://www.keyboardtester.com/tester.html — key registers as held, releases cleanly on stop

[Blur009]

I don't quite see the point here personally. reducing your click speed to once a day will just hold the key down for an entire day and you will have the same effect as what you are trying to accomplish, no? @wydvoy