Fix XWayland: it now actually renders and receives keyboard input

Three real bugs found and fixed via WAYLAND_DEBUG=1 protocol tracing in
the QEMU VM, plus a fourth found along the way:

- XWayland tried glamor (GBM rendering) first, which fails against this
  deliberately software-only compositor; its post-failure fallback path
  never used the xwayland_shell_v1 protocol at all, so X11Surface::
  wl_surface() never resolved. Fixed by shadowing `Xwayland` on PATH with
  a wrapper script that always re-execs it with -shm (smithay's
  XWayland::spawn hardcodes its own argv and can't be bypassed either,
  since XWaylandClientData's fields are private).
- Even with -shm, set_mapped(true) was only called after wl_surface()
  already resolved, deadlocking XWayland (it never advances a window past
  surface creation until the map is granted). Fixed by calling
  set_mapped(true) unconditionally in map_window_request.
- The window then rendered as a ~1px sliver: initial geometry was seeded
  from X11Surface::geometry(), which can still be a tiny default at
  MapRequest time. Fixed by using the same 800x600 default the xdg-shell
  path already uses.
- Typing didn't reach the window until a broader, XWayland-independent
  bug was fixed: nothing in the Wayland backend ever called
  KeyboardHandle::set_focus, so no window (native or X11) could ever
  receive keyboard input. Fixed in handle_pointer_button, along with
  TitlebarHit::Close being X11-surface-blind.

Verified live: xterm launched via XWayland renders correctly sized and
decorated, and a synthetic keypress sequence (ls + Enter) executed in its
shell, screendump-confirmed.

0 files changed, 0 insertions, 0 deletions