fix(input): inject a no-op input event so force-foreground actually works

Follow-up to the AttachThreadInput change: verified against an isolated repro
(a foreground-stealing window + the helper spawned exactly like the app) that
AttachThreadInput + clearing the foreground-lock timeout was NOT sufficient on
this Windows build - SetForegroundWindow still returned false and Genshin stayed
in the background.

The missing condition is "the calling process received the last input event".
Injecting a benign no-op input (a 0,0 relative mouse move, no cursor movement, no
menu-mnemonic side effect) right before SetForegroundWindow satisfies it. With the
nudge the repro now returns focused:true / setForegroundResult:true from a
background process while another app holds the foreground - the exact auto-scan
start scenario. Applied to both the C# sidecar and the PowerShell fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

electron/services/inputHelper.ts

@@ -216,6 +216,9 @@ function Force-Foreground {
     if ($foreground -ne 0 -and $foreground -ne $current -and $foreground -ne $target) { $attachedForeground = [Native.InputHelper]::AttachThreadInput($current, $foreground, $true) }
     $timeoutRead = [Native.InputHelper]::SystemParametersInfoGet(0x2000, 0, [ref]$oldTimeout, 0)
     [Native.InputHelper]::SystemParametersInfoSet(0x2001, 0, [IntPtr]::Zero, 0x0002) | Out-Null
+    # Inject a no-op input (0,0 mouse move) so this process is the last input
+    # source, which Windows requires before it will honor a foreground change.
+    Send-MouseInput -flags 0x0001 | Out-Null
     [Native.InputHelper]::ShowWindowAsync($hwnd, 9) | Out-Null
     [Native.InputHelper]::BringWindowToTop($hwnd) | Out-Null
     return [Native.InputHelper]::SetForegroundWindow($hwnd)