Add controller input and a laser-pointer-driven menu quad

- xr_input.c/h: an OpenXR action set (aim pose, trigger/select click, a
  menu-toggle button) plus ray/quad hit-testing, and a visible
  laser-pointer line drawn from the controller toward the hit point.
- xr_menu.c/h + MenuOverlay.java: a second composition-layer quad,
  toggled by a controller button, showing an off-screen, never-attached
  Android View tree (one "Keyboard" button so far) driven by synthetic
  touch events computed from the laser ray's hit UV.
- Migrate gl4es from a prebuilt binary baked into the Docker build-image
  to a vendored source snapshot (android/gl4es-src/) compiled from
  source at APK build time via CMake add_subdirectory(), patched through
  a new android/gl4es-patches/ (mirrors the existing engine-patches/
  pattern). This was needed to track down and fix a bug hit while
  building the menu: gl4es's fixed-pipeline emulation (fpe.c) was
  unconditionally substituting its own shader onto the menu's draw call
  (fpe_ReleventState() always sets alphafunc to a nonzero sentinel, so
  its fpe_IsEmpty() check could never see the state as empty), making
  the menu quad show the game's own rendering instead of its own
  content. Fixed by routing the menu's blit through a real
  glBlitFramebuffer() call instead of a shader-based draw, which gl4es's
  fpe.c has nothing to intercept - documented in README.md's new
  "Debugging notes" section.
- Renumber android/engine-patches/ to close the gap left by removing an
  unrelated diagnostic-only patch, and strip investigation-journal
  comments and dead diagnostic code (temporary tracing, env-var probes)
  left over from finding the bug above.
- Restructure README.md into numbered sections, document every
  engine/gl4es patch, add Android Studio dev/testing-cycle instructions,
  and generalize Quest-specific wording to any OpenXR headset. Update
  NOTICE.txt to match (gl4es is now vendored/patched source, not a
  prebuilt binary; add the OpenXR-SDK loader).

android/engine-patches/09-android-no-window-resize.patch

@@ -0,0 +1,29 @@
+--- a/src/MacSrc/ShockBitmap.c
++++ b/src/MacSrc/ShockBitmap.c
+@@ -42,11 +42,26 @@
+ 
+     SDL_RenderClear(renderer);
+ 
++#ifndef __ANDROID__
++    // On Android there's exactly one OS-controlled-size surface - no
++    // desktop-style window to resize, move, or toggle fullscreen on.
++    // SDL_SetWindowSize() still "succeeds" there (Android has no
++    // SetWindowSize driver hook, so SDL's generic layer just overwrites its
++    // own cached window->w/h to the requested game resolution, e.g.
++    // 640x480, and synthesizes a resize event from that) - which desyncs
++    // SDL's own notion of the window size from the real, unchanged Android
++    // surface size (e.g. 1600x1200), and that desync is exactly what then
++    // makes both SDL's internal renderer viewport and this engine's own
++    // custom GL viewport (OpenGL.cc's opengl_resize(), driven by that same
++    // now-wrong cached size) shrink to the game's resolution instead of
++    // filling the real surface. Skip the desktop-only calls on Android
++    // entirely, leaving SDL's window-size bookkeeping untouched.
+     extern bool fullscreenActive;
+     SDL_SetWindowFullscreen(window, fullscreenActive ? SDL_WINDOW_FULLSCREEN_DESKTOP : 0);
+ 
+     SDL_SetWindowSize(window, width, height);
+     SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED);
++#endif
+ 
+     SDL_RenderSetLogicalSize(renderer, width, height);
+