Fix intermittent Win+Arrow handling

[greyhair-atx]

Problem

Arrow keys could intermittently be interpreted as Windows snap shortcuts while an embedded PuTTY window had focus. The low-level keyboard hook previously inferred modifier state with GetKeyState, whose results are unreliable inside a low-level keyboard callback, and focus transitions could leave stale modifier state behind.

Changes

• Track left/right Ctrl, Shift, Alt, and Windows keys directly from low-level hook events.
• Resynchronize physical modifier state when SuperPuTTY activates and clear stale state only after focus has genuinely left SuperPuTTY and its embedded windows.
• Forward Win+Arrow snapping with SendInput instead of synthesizing Windows-key transitions.
• Mark SuperPuTTY-generated input with dwExtraInfo and ignore only those events, allowing input generated by accessibility and automation software to continue through normal handling.
• Consume the physical arrow only when foreground activation and input injection succeed; restore the previous foreground window when injection fails.
• Check and log keyboard hook installation and removal failures.
• Add focused unit tests for independent left/right modifiers, reset/synchronization, and generated-input identification.
• Correct modifier detection and trace logging issues encountered in the affected path.

Verification

• Debug build with Visual Studio 2026 MSBuild 18 / .NET Framework 4.8
• Release build with Visual Studio 2026 MSBuild 18 / .NET Framework 4.8
• Unit-test project build
• Keyboard hook state and existing keyboard shortcut tests: 7 passed, 0 failed
• Manual verification with embedded PuTTY: arrows, Win+Arrow, Win+Shift+Left/Right, Ctrl+Tab, and Alt+F4

The Release validation used a separate output directory because an existing SuperPuTTY session had the normal Release executable open.