windows: the low-level hook's modifier snapshot describes the event, not the moment before it

[iga566-gh]

Stacked on #68: this branch carries that PR's commit until it lands. The two changes touch different crates and do not depend on each other; they share a branch only so both Windows measurements below come from one build.

On Windows the manual switch-last hotkey has been stalling since 0.30, and it is not the RDP transport and not hold_keys — it is where the hook reads the modifier state from.

GetAsyncKeyState inside WH_KEYBOARD_LL reports the keyboard as it was before the event being delivered has taken effect. A Ctrl release therefore arrives reading "Ctrl held". With nothing typed afterwards that snapshot is the last one the engine gets, trigger_key_down()'s fallback sees a held set matching the chord's modifiers, and wait_for_trigger_release (the #51 pass) waits for a release it has already been handed — up to CHORD_RELEASE_WAIT, five seconds, or until the next keystroke refreshes the snapshot.

Measured on Windows Server 2025 over RDP, stock behaviour on a 0.34.0 build (debug log):

correction	applying correction → WM_INPUTLANGCHANGEREQUEST
manual hotkey, six presses	1.65 · 2.13 · 2.28 · 2.44 · 3.51 · 4.69 s
automatic (dictionary) on the same path	0.000 s

Each manual delay is exactly as long as the user took to press the hotkey again: the second press is the keystroke that refreshes the snapshot and releases the first. That second press then lands inside FORCE_SWITCH_REARM and is swallowed, or arrives as an undo of the first correction, or starts a fresh one on top — the "works on the second press, or eats the word" a user sees. convert_selection runs the same wait first, so on Windows selection conversion never got as far as a log line.

The fix is platform code, in poltertype-input. For a modifier the event is about, the event is the truth: the listener applies the delivered key's own press/release to the snapshot, reading the other side of the same modifier live so that releasing one Shift while the other is held keeps Shift. The transition itself — Modifiers::after_transition(key, pressed, other_side_down) with a small ModifierKey enum — lives in poltertype-types, platform-free and unit-tested (four tests); the VK mapping and the live reads sit in windows/modifiers.rs, a sibling of the listener, since xtask style refuses a seventh free function beside WindowsListener. Nothing changes for macOS, whose event tap hands out post-event flags already, nor for Linux, whose listeners track their own state.

Measured with the fix, same machine, same scenario: the manual switches take 0.135 · 0.262 · 0.224 · 0.218 s, none is swallowed by the re-arm window, none undoes its predecessor, and selection conversion converts — both directions, first press.

cargo xtask style clean; cargo test -p poltertype-types 6 passed; cargo clippy -D warnings clean on the host and for x86_64-pc-windows-gnu (poltertype-input, poltertype-types); the Windows release built and installed via the project's own MSI.

[vstrelnikof]

The Windows modifier-snapshot fix is correct and well-structured. GetAsyncKeyState inside WH_KEYBOARD_LL reports the keyboard state before the event has taken effect — so a Ctrl release still reads "Ctrl held", and the engine's chord-release wait stalls until the next keystroke.

The fix applies the event's own transition via Modifiers::after_transition(): a clean, platform-free method in poltertype-types with 4 unit tests covering release-clears, press-sets, other-side-held, and isolation from unrelated modifiers. The Windows-specific modifiers_for_event() in a new modifiers.rs sibling reads the other physical key of the same modifier live. Nothing changes for macOS or Linux — correct.

407 core tests + 6 types tests pass, clippy clean on the host.