Split the menu quad back onto its own independent OpenXR swapchain

Replaces the single shared, side-by-side swapchain (game + menu content
packed into one image, needing viewport/scissor juggling to keep the
menu's own glClear from bleeding into the game's region) with two fully
independent XrSwapchainState instances, each sized to exactly its own
content and acquired/released on its own within the same
xrBeginFrame/xrEndFrame pair - an ordinary multi-layer OpenXR setup.

The shared-swapchain design was originally adopted to work around what
looked like a Horizon OS compositor limitation with independent
swapchains, but that was diagnosed before the real root cause of the
"menu shows the game's content" bug was found (gl4es's fpe.c
unconditionally substituting its own shader onto the menu's draw call -
see README's Debugging notes). Since the actual fix routes the menu's
blit through a real, non-gl4es glBlitFramebuffer() call - orthogonal to
how many swapchains exist - splitting back onto two swapchains works
fine and removes the GL_SCISSOR_TEST workaround and sub-rectangle
offset math entirely. Confirmed on-device: both quads render correctly,
hit-testing and 90 FPS unaffected.

Also adds a visible cursor to the menu quad itself: xr_input.c now
tracks whichever hand's aim ray hits the menu each frame and forwards it
to a new MenuOverlay.nativeUpdateCursor(), which draws a small dot at
that position (composited through the same Bitmap the menu's own
content already goes through) - previously there was no visual feedback
at all showing where you were pointing before pulling the trigger.

README.md

@@ -140,12 +140,17 @@ can be sideloaded onto any Android-based VR headset with OpenXR support
 vendor's store. The game's own rendering is unchanged (still a flat, 2D
 render, no stereo 3D scene), but instead of running as a Home-hosted 2D
 panel it's now shown as a single head-tracked quad floating in front of
-the viewer in an otherwise empty space. There's no controller-driven
-interaction yet (that's ongoing work - a laser-pointer-driven menu and
-on-screen keyboard); for now, play with a Bluetooth mouse/keyboard
-connected to the headset same as before. (Only tested on Meta Quest so
-far - the steps below use Quest-specific tool names where relevant, but
-the same `adb install` flow applies to any Android headset with USB
+the viewer, with a separate menu quad (currently just one "Keyboard"
+button - the actual on-screen keyboard behind it is still ongoing work)
+toggled by a controller button and driven by a laser-pointer-style aim
+ray from each hand (`android/app/src/main/cpp/xr_input.c`) - point and
+pull the trigger to interact with the menu, same as the game's own
+Bluetooth mouse/keyboard input otherwise works unchanged. The laser
+pointer/cursor is currently only visible while actually aiming at the
+game or menu quad respectively - there's no visual feedback yet while
+aiming at empty space between them. (Only tested on Meta Quest so far -
+the steps below use Quest-specific tool names where relevant, but the
+same `adb install` flow applies to any Android headset with USB
 debugging enabled.)
 
 ### 5.1. Installing and playing