fix(kbm): Handle SendVirtualInput failures and release modifiers for text remap

[crutkas]

Summary

Fix Keyboard Manager stuck key bugs where SendVirtualInput failure causes keys to vanish, and held modifiers corrupt text injection.

Changes

C1: SendVirtualInput returns bool — pass through on failure

• Changed InputInterface::SendVirtualInput from void to bool
• Returns false when SendInput injects fewer events than expected
• All 8 call sites that suppress the original key (return 1) now check the return value — if injection fails, return 0 passes through the original key instead of eating it
• Updated MockedInput test double to match new signature

C4: Release held modifiers before text injection

• In HandleSingleKeyToTextRemapEvent, detect held modifiers via GetAsyncKeyState
• Release Ctrl, Shift, Alt, and Win keys before SendTextInput
• Re-press them after text injection
• Prevents Ctrl+text, Win+text corruption
• Return value checked on modifier release — passes through original key if release fails

New Unit Tests (3 tests)

• HandleSingleKeyRemapEvent_ShouldPassThrough_WhenSendVirtualInputFails — verifies key not eaten on failure
• HandleSingleKeyToTextRemapEvent_ShouldReleaseAndRestoreCtrl_WhenCtrlIsHeld
• HandleSingleKeyToTextRemapEvent_ShouldReleaseAndRestoreWinKey_WhenWinKeyIsHeld

How to Reproduce

C1 — Key eaten on failure: Hard to reproduce directly (requires SendInput to fail), but verified via unit test with mocked failure.

C4 — Modifier corruption:

1. In KBM, remap key X to text "hello"
2. Hold Ctrl and press X
3. Before fix: Types Ctrl+h, Ctrl+e, Ctrl+l, Ctrl+l, Ctrl+o (triggering shortcuts instead of text)
4. After fix: Releases Ctrl, types "hello", re-presses Ctrl

How to Verify

1. All 95 unit tests pass (92 existing + 3 new)
2. Manual: remap a key to text, hold Ctrl/Win/Shift while pressing it — text types correctly

Related Issues

• Fixes Keyboard shortcut causes Ctrl key to act stuck microsoft/PowerToys#17035 — "Keyboard shortcut causes Ctrl key to act stuck"
• Fixes Keyboard Manager causes Ctrl key to get "stuck" microsoft/PowerToys#29015 — "Keyboard Manager causes Ctrl key to get stuck"
• Fixes Ctrl key gets stuck when using Keyboard Manager with Alt key microsoft/PowerToys#9778 — "Ctrl key gets stuck when using Keyboard Manager with Alt key"

PR Checklist

• Builds clean on x64 Release
• 95/95 unit tests pass
• New tests added for failure paths

[yeelam-gordon]

At HandleSingleKeyToTextRemapEvent (KeyboardEventHandlers.cpp ~L1823-1862) the release / SendTextInput / restore sequence has a narrow but real race:

for (int vk : modifierKeys)
    if (ii.GetVirtualKeyState(vk))
        // queue release + remember in releasedKeys
ii.SendVirtualInput(releaseEvents);
Helpers::SendTextInput(*remapping);   // <-- user can release the physical modifier here
// unconditionally re-press releasedKeys
ii.SendVirtualInput(restoreEvents);

If the user physically lets go of the modifier during SendTextInput (very plausible for a long remap text), the unconditional re-press leaves Windows believing the modifier is virtually held while the physical key is up i.e. the exact stuck-modifier class this PR family targets. The user has to tap the modifier again to resync.

Suggested fix: query GetAsyncKeyState(vk) & 0x8000 immediately before each re-press and only re-press modifiers still physically held:

for (int vk : releasedKeys)
{
    if (GetAsyncKeyState(vk) & 0x8000)
        Helpers::SetKeyEvent(restoreEvents, INPUT_KEYBOARD, static_cast<WORD>(vk), 0,
                             KeyboardManagerConstants::KEYBOARDMANAGER_SHORTCUT_FLAG);
}

Tests in SingleKeyRemappingTests.cpp cover the synchronous failure path nicely adding one for "user releases modifier mid-text" would make this airtight.

[crutkas]

Good catch on the release/re-press race. I dug into the GetAsyncKeyState & 0x8000 "re-press only if still physically held" suggestion and it turns out to be unworkable: injecting the modifier's own KEYUP flips GetAsyncKeyState to up, so by the time we'd evaluate the guard it always reports the modifier released — the re-press would become dead code.

So I dropped the re-press entirely. Modifiers are released before the text is injected (SendTextInput uses KEYEVENTF_UNICODE, so it's modifier-independent) and never re-pressed, which guarantees this path can't leave a modifier stuck down. Cost is that the user re-taps the modifier to re-engage it. Added tests asserting the modifiers end released and that there are zero modifier re-press injections, including the "user releases the modifier mid-text" case.

[crutkas]

Superseded by the upstream PR against microsoft/PowerToys: microsoft#48571 (rebased onto current main, builds/tests verified). Closing this intra-fork review PR.