fix(windows): stop retrying SendInput forever when it is refused

[minh-tg]

On Windows, SendInput returns 0 when it does not insert an event. That happens when UIPI
blocks it, for example while a window started as administrator has focus, or when another
thread blocked input. Microsoft documents that neither the return value nor GetLastError
says which one it was.

send_input_safe called SendInput in a loop until it returned non-zero. For as long as the
refusal lasted, the loop did not end. The daemon runs on a single-threaded runtime, so input
and IPC stopped, and so did the cleanup that releases held keys. The key repeat task had the
same loop.

Changes:

• send_input makes one attempt and returns an error if it fails. Retrying in a loop would
  block the runtime again.
• The error ends the emulation session like any other emulation error. Releasing held keys
  is attempted on the way out, but it goes through the same call and is refused too while the
  cause lasts, so held keys can stay pressed. Making release_keys continue past a refused release is a separate change.
• The key repeat task logs the failure and stops repeating.
• The README lists the limitation under Known Issues, including the held keys.

With an elevated window focused, the log now shows
input emulation exited: ... SendInput refused the event, and emulation stays off until it is
enabled again from the frontend. Before, the daemon froze.

I have not run this on Windows because I don't have a machine. CI compiles it. To check by hand:
run lan-mouse on Windows, focus a window started as administrator, send a key from the other
machine, and confirm the log line above and that emulation shows as disabled. Then enable it
again and confirm input works.

Related: #404 reports that Task Manager, which runs elevated, cannot be controlled and that input stops once it has focus. That may be this freeze. This change does not make elevated windows controllable. #373 proposes running as a Windows service, which would. #469 and #513 also edit windows.rs, so whichever merges second needs a rebase.

[minh-tg]

CI is waiting for approval to run. Could a maintainer approve it when you have a moment? Thanks!

[minh-tg]

Reworked after a second look. The three immediate retries are gone because nothing changes
between them. The comment on the repeat task is corrected (the error does not reach the caller,
it is logged), and the DOC.md change is dropped because that file describes the architecture,
not individual backends. The README now documents the limitation instead.