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>

AGENTS.md

@@ -297,6 +297,17 @@ Each exists because something was invisible without it.
   into it. The emulator is for JNI, the IME, insets, the surface
   lifecycle and one verification run before a build goes to the phone --
   not for iterating on layout.
+- **The emulator is a GLES rig, deliberately** (Iris, 2026-09-08;
+  docs/DECISIONS.md). Its guest has no hardware Vulkan -- only SwiftShader
+  in software -- while its GLES *is* the host's real GPU through virgl at
+  ES 3.1, so an ordinary build's runtime fallback lands there by itself
+  and nothing should pass `force-gles` to arrange it. The Vulkan path is
+  verified on the desktop build and on Iris's phone. Do not boot the
+  emulator with SwiftShader Vulkan to "test the Vulkan path": that
+  measures a software rasteriser and steers iris away from the one
+  hardware-accelerated backend it has there. Every run says which adapter
+  drew it (`iris renderer:` in logcat, printed by `run-bench.sh`); read
+  that line before reading a number.
 
 ### Driving the UI