iris: the Android renderer falls back to GLES, and every failure reports

The bench app crash-looped on this checkout's emulator with the default
features (RUST.md's queue item). Not the surface lifecycle and not "once
backgrounded": a build without `force-gles` never got a first frame.
`AndroidRenderer::new` asked wgpu for `Backends::PRIMARY`, which does not
contain `GL`, and this emulator advertises a Vulkan ICD with no adapter
behind it -- `NotFound { active_backends: VULKAN, no_adapter_backends:
VULKAN, supported_backends: VULKAN | GL }`, `.expect`ed, so SIGABRT, so
the launcher restarts it. iris was refusing a device whose only usable
adapter is a GLES one.

It now probes for a `PRIMARY` adapter and rebuilds the instance on
`Backends::GL` when there is none. The probe runs on an instance that
never touches the window on purpose: **an Android window can be
connected to one graphics API only**, so one instance carrying both
backends fails worse -- measured here on the way to this fix, Vulkan's
`vkCreateAndroidSurfaceKHR` claims the window in `create_surface` and
the GLES surface from the same window then reports `In
Surface::configure / Invalid surface`, aborting a frame later in
`Surface::get_current_texture_view`. Vulkan still wins wherever it has
an adapter (`PowerPreference::None` does not sort, and Vulkan is
enumerated first), so nothing changes on the phone.

Second half, the same rule applied to the whole set: the surface,
adapter and device requests all report through the `Result<Self,
String>` this function already returns, where two of the three used to
panic. `surface_changed` puts that string on screen and in the log
ring, which is what the Result was added for.

Emulator evidence (API 36 x86_64, debug): after, `iris renderer: no
Backends(VULKAN | METAL | DX12 | BROWSER_WEBGPU) adapter on this
device, falling back to GLES` then `new renderer built (Gl)` and
frames. Clean on both the default and a `force-gles` build for the
cases this had no reason to touch: two background/return cycles,
rotation there and back (the `already_live=true` reuse branch), a
background/return after the rotation, and cold starts. Vulkan could not
be exercised here -- that this emulator has no Vulkan adapter is the
defect itself.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/IRIS.md

@@ -8,6 +8,28 @@ capability that moved. Small and trivial changes do not go here.
 An entry gives the date, what changed, why, and a short before/after where
 it helps judge the change without the session that made it. Newest first.
 
+## 2026-09-07: iris runs on a GLES-only Android device, and reports the renderer it cannot build
+
+`AndroidRenderer::new` asked wgpu for `Backends::PRIMARY`, which does not
+include `GL`. A device that offers a Vulkan driver with no adapter behind
+it -- this checkout's emulator -- therefore had no adapter at all, and the
+`.expect` on that turned into a crash loop with nothing on screen. It now
+probes for a `PRIMARY` adapter first and falls back to `Backends::GL` when
+there is none, so **Vulkan still wins wherever it has an adapter** and
+nothing changes on a phone.
+
+The probe deliberately runs on an instance that never touches the window:
+an Android window can be connected to one graphics API only, so an
+instance carrying both backends lets Vulkan claim the window and leaves
+the GLES surface unusable. That is why this is a second instance rather
+than one wider `Backends` value.
+
+The other half a caller sees: `AndroidRenderer::new` already returned
+`Result<Self, String>`, and now **every** way it can fail goes through
+that -- no surface, no adapter, no device, as well as the bind-group
+validation failure it was originally written for. `surface_changed` puts
+that string on screen and in the log ring instead of aborting.
+
 ## 2026-09-07: `VelocityTracker` takes positions, not deltas
 
 A flick released at the wrong speed because the tracker averaged. It now