Merge remote-tracking branch 'origin/rustify' into worktree-agent-a27094a7db775552a

# Conflicts:
#	docs/IRIS.md

docs/RUST.md

@@ -59,6 +59,21 @@ session spending an afternoon on them again.
   end-to-end this pass. The fix itself is verified by direct, targeted
   logcat traces taken before that interference began, not by the
   aggregate script.
+- **iris no longer requests compute-shader limits it never uses,
+  2026-09-05.** `adapter.request_device`'s `Limits::default()` asks for
+  desktop-tier compute limits unconditionally even though nothing in
+  `iris`/`iris-core` uses a `ComputePipeline` -- confirmed by grep, not
+  assumed -- which is what crashed `request_device` outright under
+  `EMU_GPU=software`'s `force-gles` path (SwiftShader's GL reports OpenGL
+  ES 3.0, no compute at all). New shared `iris_core::device_limits()`
+  zeros exactly the six compute fields; `rigs/gpu-probe`'s own mirrored
+  limits were updated and confirm `IRIS DEVICE: ok` on this VM's own
+  Vulkan and GL adapters. **The specific SwiftShader-ES-3.0 crash this
+  fixes was not re-verified on-device this pass** -- the cold boot needed
+  would have force-restarted this checkout's emulator while another
+  session had its own app focused on it, so it was left rather than
+  disrupted. See this box's "Fixed, 2026-09-05, later the same day"
+  subsection (under the software-mode crash it fixes) and `DECISIONS.md`.
 - **Decided 2026-09-05: iris over Masonry**, by Iris, from the host-GPU
   numbers in I5's box and E1/E2's findings. See the Recommendation's item
   3 and `DECISIONS.md`. Next: the remaining screens and the app on iris —
@@ -3211,6 +3226,45 @@ silently on real hardware.
       general) explains the ~80-150ms software-mode numbers, since no GLES
       number under software mode could be taken at all.
 
+      **Fixed, 2026-09-05, later the same day.** Not "requesting compute
+      limits only when the adapter reports them" (a capability check with
+      a fallback) -- simpler than that, because iris has no code path that
+      needs compute at all: grepped the whole `iris`/`iris-core` tree for
+      `ComputePipeline`/`@compute` and found none, so the right fix is to
+      stop asking for compute limits, full stop, rather than to build a
+      fallback for a capability nothing uses. `iris_core::device_limits()`
+      (`iris/core/src/render/mod.rs`) is the one place both platform
+      backends now build their `required_limits` from: `Limits::default()`
+      with the six `max_compute_*` fields zeroed and `max_buffer_size`
+      still raised, as before. `Limits::downlevel_webgl2_defaults()` was
+      the first thing tried and rejected -- it also zeros
+      `max_storage_buffers_per_shader_stage`, and `shader.wgsl`'s vertex
+      stage reads four `var<storage>` buffers, so it would have traded
+      this crash for a bind-group-layout one on the same hardware.
+      `rigs/gpu-probe`'s own `Limits` (necessarily a hand-mirrored copy --
+      that rig is deliberately its own crate, not a workspace member) was
+      updated to match and re-run: `IRIS DEVICE: ok` against this VM's own
+      Vulkan (Venus) and GL (virgl, reports OpenGL ES 3.2) adapters.
+      **Not verified against the actual SwiftShader-ES-3.0 failure this
+      pass**: the `EMU_GPU=software` cold boot needed to reproduce it would
+      have force-restarted this checkout's shared emulator while another
+      session had `com.example.aiapp` focused and running on it (`adb
+      shell dumpsys window`), so this pass left that measurement rather
+      than disrupting concurrent work -- matching AGENTS.md's "coordinate
+      with peer agents" guidance rather than contending for the emulator.
+      Everything else: `cargo fmt --all`/`clippy --workspace --all-targets`/
+      `test --workspace` clean, `cargo ndk build`/`clippy` for
+      `iris-android-app --features transcript-screen,force-gles` clean
+      (only the pre-existing unused-`tabs-ui`-dependency warning, unrelated
+      to this change). This also means the software-mode question two
+      boxes up is still open, for the same original reason plus this new
+      one: a GLES number under `EMU_GPU=software` still has not been
+      taken, now blocked on emulator availability rather than on the
+      crash. A future pass should cold-boot `EMU_GPU=software` once the
+      emulator is free, confirm `dev.iris.android.demo` no longer aborts
+      on `request_device`, and take the `iris-scroll.sh` FrameReport row
+      that pairs with this box's host-GPU one.
+
       **Verification, this update.** `cargo fmt --all` (no diff),
       `cargo clippy --workspace --all-targets` (no warnings from the new
       code; pre-existing `wgpu`/`winit`/`naga` future-incompat notices