Add mouse + keyboard forwarding (MKB subsystem, opt-in)

Forward the host window's clicks and keystrokes into the injected game so guests
can drive menus / "Press Start" / text entry that a pad can't.

Protocol (v7->v8): new HookSubsys_Mkb and an SPSC MkbRing of MkbEvents in
SharedBlock (host produces, hook consumes); push/pop helpers.

Hook (hook/src/mkb_hook.cpp, new subsystem): a worker-loop pump drains the ring at
~5 ms and PostMessageW's the matching window messages (WM_KEY*/WM_CHAR, mouse
buttons, WM_MOUSEWHEEL) to the game's main window; it also inline-hooks user32
GetAsyncKeyState / GetKeyboardState / GetCursorPos (stdcall trampolines per the x86
rule) to report a synthesized state so polling games react too. Removing the
subsystem clears all synthesized keys (no stuck input).

Host: the Injection panel gets a "Mouse + keyboard forwarding" subsystem toggle
(opt-in, default off -- the toggle is the hook). host/src/inject/mkb_forward.cpp
reads ImGui IO each frame and forwards only when the host window is focused and
ImGui isn't capturing the event; keyboard always, mouse only while mirroring (clicks
+ wheel, not movement). Mouse coords are mapped through the letterbox to game-client
space (host/src/inject/mkb_map.hpp), accounting for WGC-of-decorated-window vs
hooked/borderless. RawInput/DirectInput games are out of scope for this version.

Verified: new mkb_ring_test + mkb_map_test pass; full build x64 + x86 clean; ctest
x64 9/9 and x86 3/3 green (no regression from the protocol bump). The subsystem is
opt-in, so it can't affect existing behavior unless enabled; the end-to-end
click-into-game path needs live Remote Play + a real game to confirm.

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

README.md

@@ -25,6 +25,7 @@ and forwards guest controllers back into it.
 | --- | --- | --- |
 | Receive guest input | XInput (RPT delivers guest pads to the focused window); optional, opt-in Steam Input when built with the Steamworks SDK | `coop_host.exe` |
 | Forward input to game | DLL injection + XInput hook (SafetyHook) — game sees *only* our pad | `coop_hook.dll` |
+| Forward mouse + keyboard | Opt-in MKB subsystem: host streams its window's clicks/keys, the hook posts the matching window messages and synthesizes `GetAsyncKeyState`/`GetKeyboardState`/`GetCursorPos` for polling games | `coop_hook.dll` + `coop_host.exe` |
 | Keep game running unfocused | Hook spoofs focus so the game polls while the host holds OS focus | `coop_hook.dll` |
 | Mirror video (default) | Windows Graphics Capture of the game window, letterboxed into the host window | `coop_host.exe` |
 | Mirror video (hooked) | Injected Present / OpenGL hook copies the backbuffer into a shared keyed-mutex texture the host samples (lower latency, no capture border) | `coop_hook.dll` + `coop_host.exe` |
@@ -75,23 +76,6 @@ is removed from this list once done — so the top item is always next. The
 self-verifiable tooling / UI / input items come first; the game-pipeline items that
 need a real game (and Remote Play) to fully validate come last.
 
-- **Mouse & keyboard forwarding (messages + polling-state hooks).** Forward guest
-  clicks and keystrokes into the unfocused game via a new **MKB hook subsystem** in
-  `coop_hook.dll` — the toggle *is* the hook (not installed → no forwarding).
-  *Delivery:* `PostMessage` window-message input (`WM_KEYDOWN`/`WM_KEYUP`/`WM_CHAR`,
-  `WM_*BUTTONDOWN`/`UP`, `WM_MOUSEWHEEL`) to the game HWND, **plus** hook
-  `GetAsyncKeyState` / `GetKeyboardState` / `GetCursorPos` in the DLL so polling games
-  see the synthesized keyboard/cursor state (RawInput and DirectInput games are out of
-  scope for this version). *Keyboard* is always forwarded; *mouse* only while video is
-  mirrored (otherwise the operator can't see where they click), and only **clicks +
-  wheel, not movement** (one cursor can't be in two places). *Coordinate mapping* (the
-  part that must be exact): WGC + decorated windowed → translate by the window
-  decoration / client-area offset; hooked capture → relative to the mirrored viewport
-  only (decorations aren't mirrored); borderless → the same under both backends.
-  *Critical gating:* forward only when the host's main window is focused **and** ImGui
-  doesn't want the event (`ImGuiIO::WantCaptureMouse` / `WantCaptureKeyboard`), so
-  interacting with the overlay's own windows never leaks input into the game. The host
-  sends MKB events to the hook over a new (or extended) IPC region.
 - **Rumble / haptics forwarding (both backends).** Currently unsupported — the XInput
   hook swallows `XInputSetState`. Add a reverse path: the hook captures the game's
   `XInputSetState` (left/right motor) and publishes it over a hook→host channel (the