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/02-android-opengl-es.patch

@@ -1,19 +1,30 @@
---- a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -46,9 +46,17 @@
-
+diff -ru a/CMakeLists.txt b/CMakeLists.txt
+--- a/CMakeLists.txt	2026-07-31 14:04:53.195646458 +0200
++++ b/CMakeLists.txt	2026-07-31 14:05:05.703429751 +0200
+@@ -46,9 +46,27 @@
+ 
  add_compile_options(-fsigned-char -fno-strict-aliasing)
-
+ 
 -# Find OpenGL
 +# Find OpenGL. Android has no desktop GL/GLX for CMake's FindOpenGL module
-+# to find - link the prebuilt GL4ES instead (translates this file's
++# to find - build GL4ES from source instead (translates this file's
 +# desktop-style GL calls into GLES/EGL; it links GLESv2/EGL itself, so
-+# the engine doesn't need to link them directly).
++# the engine doesn't need to link them directly), via add_subdirectory
++# rather than a prebuilt .so: ANDROID_GL4ES_DIR (passed in by
++# android/app/build.gradle, same as ANDROID_PREBUILT_DIR) is a scratch,
++# patched copy of android/gl4es-src/ staged by
++# build-image/prepare-android-project.sh (mirrors how this file itself is
++# staged/patched before Gradle ever sees it) - building it as part of this
++# same CMake configure means Gradle's own incremental CMake/Ninja build
++# only recompiles it when gl4es-src/gl4es-patches actually changed, same
++# as this file, instead of needing a full build-image rebuild for every
++# gl4es-patches change.
  if(ENABLE_OPENGL)
 -	find_package(OpenGL REQUIRED)
 +	if(ANDROID)
-+		set(OPENGL_INCLUDE_DIRS ${ANDROID_PREBUILT_DIR}/gl4es/include)
-+		set(OPENGL_LIBRARIES ${ANDROID_PREBUILT_DIR}/gl4es/lib/libGL.so)
++		add_subdirectory(${ANDROID_GL4ES_DIR} ${CMAKE_BINARY_DIR}/gl4es-build)
++		set(OPENGL_INCLUDE_DIRS ${ANDROID_GL4ES_DIR}/include)
++		set(OPENGL_LIBRARIES GL)
 +	else()
 +		find_package(OpenGL REQUIRED)
 +	endif()

android/engine-patches/03-android-gles-context.patch

@@ -9,7 +9,7 @@
 +    // Android - EGL only ever gives out GLES contexts. Quest hardware
 +    // (Adreno on the XR2/XR2 Gen 2) supports GLES 3.2, which - unlike
 +    // GLES 2.0 - has GL_UNPACK_ROW_LENGTH and GL_CLAMP_TO_BORDER as core
-+    // (see android/engine-patches/03-android-opengl-es-render.patch),
++    // (see android/engine-patches/04-android-opengl-es-render.patch),
 +    // avoiding needing workarounds for either in OpenGL.cc.
 +    SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
 +    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);

android/engine-patches/07-android-size-diagnostics.patch

@@ -1,24 +0,0 @@
---- a/src/MacSrc/OpenGL.cc
-+++ b/src/MacSrc/OpenGL.cc
-@@ -332,6 +332,21 @@
- 
-     int width, height;
-     SDL_GetWindowSize(window, &width, &height);
-+#ifdef __ANDROID__
-+    // Temporary diagnostic: the reported panel/surface size is correct
-+    // (confirmed via SDLSurface's own "Window size" log and a Java-side
-+    // onSizeChanged() probe showing no later relayout), but the rendered
-+    // content still only fills a small corner of it. That means the
-+    // divergence is somewhere below the Java/Activity layer - between what
-+    // SDL_GetWindowSize() (the value used for opengl_resize() below) reports
-+    // and what SDL/EGL/gl4es actually believe the live drawable size is.
-+    // Compare all three directly instead of guessing further.
-+    int drawable_w, drawable_h, output_w, output_h;
-+    SDL_GL_GetDrawableSize(window, &drawable_w, &drawable_h);
-+    SDL_GetRendererOutputSize(renderer, &output_w, &output_h);
-+    INFO("Android size diag: SDL_GetWindowSize=%dx%d SDL_GL_GetDrawableSize=%dx%d SDL_GetRendererOutputSize=%dx%d",
-+         width, height, drawable_w, drawable_h, output_w, output_h);
-+#endif
-     opengl_resize(width, height);
- 
-     // Now make the palettes

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

@@ -1,6 +1,6 @@
 --- a/src/MacSrc/ShockBitmap.c
 +++ b/src/MacSrc/ShockBitmap.c
-@@ -42,11 +42,28 @@
+@@ -42,11 +42,26 @@
  
      SDL_RenderClear(renderer);
  
@@ -16,10 +16,8 @@
 +    // 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 - confirmed on-device via added logcat
-+    // diagnostics (see android/engine-patches/07-09) showing the correct
-+    // 1600x1200 size at startup, then this exact call sequence collapsing
-+    // it to 640x480 the moment the splash screen sets its video mode.
++    // 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);