emulator: settle on GLES, and make every run say which adapter drew it

Iris's call, after the guest measurement: the emulator is a GLES rig and
nothing chases hardware Vulkan in it; the Vulkan path is covered by the
desktop build and by her phone.

Nothing had to be forced. The emulator has no hardware Vulkan at all --
its only Vulkan is SwiftShader in software -- and its GLES is the host's
real RX 7900 XT through virgl at ES 3.1, so iris's existing runtime
fallback lands there by itself. Verified end to end with an ordinary
debug APK: "no Backends(VULKAN|...) adapter on this device, falling back
to GLES", then "Android Emulator OpenGL ES Translator (virgl (AMD Radeon
RX 7900 XT ...)) (Gl, OpenGL ES 3.1 ...) on Backends(GL)". So the
emulator and the phone run the same binary, differing only in what it
finds -- which is the point, and `force-gles` must not be reintroduced to
arrange the emulator's backend.

What changed:
- The Android renderer logs the full adapter line at startup, as the
  desktop already did. Only the backend enum was logged, which cannot
  tell `Gl` on the host's GPU from `Gl` on SwiftShader; the same rule was
  written on one member of the pair and not the other.
- `run-bench.sh` prints that line before any number.
- build-apk.sh, Cargo.toml and RUST.md's "Vulkan in the emulator" carried
  the stale premise that the emulator defaults to software Vulkan and has
  to be steered off it. The recipes are marked superseded rather than
  deleted, since the record of why host Vulkan is unavailable is still
  worth having.
- Drive-by: an `#[allow]`-free clippy warning in android/platform.rs
  (useless JObject conversion) that only appears on the android target.

No Vulkan requirement was found in iris itself to remove: neither backend
asks for a feature, `device_limits()` stays at wgpu's defaults with the
compute fields zeroed, and both probe rather than expect an adapter.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/DECISIONS.md

@@ -5,6 +5,38 @@ they can be judged and reversed later. Detail lives in RUST.md (and IRIS.md
 for iris API changes); this file is only the summary. Newest first. Items
 marked **DEFERRED** are ones the agent chose not to decide alone.
 
+## 2026-09-08 (the emulator is a GLES machine, and Vulkan is verified elsewhere)
+
+- **Directed by Iris, carried out here**: "make sure the setup uses GL for
+  the android emulator and remove any vulkan requirements. That'll be
+  tested through both the desktop version as well as my phone." So the
+  emulator is settled as a GLES rig and nothing chases hardware Vulkan in
+  it any more; the Vulkan path is covered by the desktop build and by her
+  phone.
+- **Nothing had to be forced to make that true.** Measured in the guest
+  the same day: the emulator has no hardware Vulkan at all (its only
+  Vulkan is SwiftShader, in software) and its GLES is the host's real RX
+  7900 XT through virgl at ES 3.1. iris's existing runtime fallback --
+  `Backends::PRIMARY`, no adapter, rebuild on `Backends::GL` -- already
+  lands there, verified end to end with an ordinary (no `force-gles`)
+  debug APK.
+- **The emulator and the phone therefore run the same binary**, differing
+  only in what that binary finds. That is deliberate and worth not
+  undoing: a build flag that changed the backend would mean the thing
+  measured on the emulator is not the thing shipped. `force-gles` stays,
+  but only for pinning the backend on a machine that *does* have Vulkan
+  (the desktop), and never for a phone build.
+- **Every run now says which adapter drew it.** The Android renderer logs
+  the full adapter line at startup the way the desktop already did -- only
+  the backend enum was logged before, which cannot separate `Gl` on the
+  host's GPU from `Gl` on SwiftShader, or a phone's real Vulkan from a
+  software one. `run-bench.sh` prints that line before any number.
+- **No Vulkan requirement was found in iris to remove.** `device_limits()`
+  asks for nothing beyond wgpu's defaults (and zeroes the compute fields),
+  neither backend requires a feature, and both probe rather than
+  `.expect()` an adapter. What was removed was the *documentation* telling
+  people to boot the emulator with SwiftShader Vulkan.
+
 ## 2026-09-07 (platform fonts, not bundled ones)
 
 - **Iris's own decision, carried out as directed**: removed the 3.6 MB of

docs/RUST.md

@@ -7706,9 +7706,21 @@ as external-memory modes, so there is nothing to switch to. The retry
 costs one boot; do it again when either the emulator package or Mesa
 moves.
 
-### Vulkan in the emulator (measured 2026-09-04)
+### Vulkan in the emulator (measured 2026-09-04, superseded 2026-09-08)
 
-**Settled 2026-09-04: the guest gets Vulkan from SwiftShader, and the
+**Do not follow the recipes below.** Iris settled the posture on
+2026-09-08: the emulator is a **GLES** rig, tested on the host's real GPU
+through virgl, and the Vulkan path is covered by the desktop build and by
+her phone (docs/DECISIONS.md, 2026-09-08). Booting the emulator with
+SwiftShader Vulkan gets a *software* Vulkan device, which is a slower and
+less representative thing to measure than the GLES path that runs on real
+hardware -- and it makes iris pick that software device over the fast
+path, since the fallback only reaches for GLES when Vulkan has no adapter
+at all. This section stays as the record of **why host Vulkan is not
+available here** and what was ruled out, so the question is not
+re-opened from scratch.
+
+**Measured 2026-09-04: the guest can get Vulkan from SwiftShader, and the
 missing step was a cold boot.** `-feature Vulkan` plus
 `VK_DRIVER_FILES=$HOME/Android/Sdk/emulator/lib64/vulkan/vk_swiftshader_icd.json`
 gets the *host* side to select SwiftShader, but the guest keeps reporting