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/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