fix: route X11 keyboard input through xdotool XTEST (#58)

[avifenesh]

Summary

Fixes #58. Thanks @martin152 — the raw-ydotool key vs tool comparison in the report isolated this precisely.

Root cause. press_key and type_text both went through ydotool on X11. ydotool writes raw evdev scancodes to a virtual uinput device; X11 then re-interprets those scancodes through the active XKB layout. So:

• press_key "Return" / ctrl+a / ctrl+s → stray glyphs, no real key event
• type_text → symbols and digits mangled (_ → %, 1 → +), letters survive

This is why raw ydotool key 28:1 28:0 worked in the reporter's test but the tool did not: the numeric-keycode path is fine at the uinput layer, but the scancode → layout translation is what breaks under X11.

Fix. On non-Wayland sessions with DISPLAY set and xdotool present, both tools use xdotool (XTEST), which resolves keysyms against the live layout — what X11 clients actually expect.

• press_key → xdotool key --clearmodifiers <spec> (e.g. ctrl+a, Return, super+Return)
• type_text → xdotool type --clearmodifiers -- <text>
• The xdotool spec is validated through the existing key_chord parser, so both backends accept exactly the same key surface — no silent widening/narrowing, and the "never silently dropped" error is preserved.
• ydotool remains the fallback when xdotool is missing or the call fails.
• Wayland is untouched (portal / KDE clipboard / ydotool ordering unchanged).
• doctor now reports an xdotool input backend on X11.

Escape hatches:

COMPUTER_USE_LINUX_FORCE_YDOTOOL_KEYBOARD=1    # opt out, old behaviour
COMPUTER_USE_LINUX_FORCE_XDOTOOL_KEYBOARD=1    # force XTEST

Test plan

• Unit tests: named-key → keysym mapping, chord modifier prefixes, bare modifier, and a grammar-parity test asserting xdotool_key_spec accepts exactly what key_chord accepts
• cargo fmt / cargo clippy -D warnings / full cargo test green
• Verified end-to-end on a real X server (Xvfb :97 + xterm, driven through the MCP server over stdio):
  • type_text "RAW_LINE1 _ 1 __ 11" → landed byte-exact, no %/+ mangling
  • press_key "Return" → produced a real newline (confirmed by reading what the terminal received, not by AT-SPI)
  • both responses reported Action sent through xdotool (X11 XTEST).

Note for @martin152: the xdotool package is now what makes X11 keyboard input correct — it's a soft dependency (ydotool still used as fallback), and doctor will list it once installed.

Closes #58

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.