iris: replace the bindless texture array with an atlas array + per-image bind groups

The old pipeline bound every texture ever drawn (glyph atlas pages and
standalone images alike) in one binding_array<texture_2d<f32>> and asked
every device, unconditionally, for VK_EXT_descriptor_indexing -- which a
real share of Android GPUs lack and which failed outright on the Android
emulator's software Vulkan (see TEXTURES.md's "iris's binding array does
not survive real Android hardware").

Implements TEXTURES.md's "Recommended shape": the glyph atlas is now one
texture_2d_array (a layer per page, grown by doubling + GPU-side
copy_texture_to_texture); a standalone image is its own ordinary Texture
and BindGroup, drawn with its own draw() call from a separate per-layer
instance list; group 2's layout is {atlas array, one image slot, sampler,
masks}. request_device now asks for no features and no binding-array
limits at all, and UiLimits is gone.

Also fixes (by making moot) the changed=false bug the review found, where
a Patch in the same batch could cancel an earlier Push's rebuild signal,
and documents the swap_remove draw-order invariant apply_free already
relied on.

Verified: cargo fmt/build/clippy/test clean in iris/ on the pinned
nightly; minimal and tabs render correctly via run-headless.sh; a
throwaway example confirmed the standalone-image bind-group path renders;
rigs/gpu-probe, updated to the new empty feature/limit set, confirms
request_device succeeds on the ai-app-2 emulator's software Vulkan
(EMU_GPU=software) -- see TEXTURES.md's "Implemented, 2026-09-04" for the
exact command and output. RUST.md's blocking item is resolved.

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

RUST.md

@@ -46,19 +46,25 @@ session spending an afternoon on them again.
   android-view's `accesskit_android` adapter also has a reproducible abort
   (a client detaching, not attaching, is the trigger) — see E1 below for
   both, with the mitigation iris/I4 needs to carry.
-- **Blocking, found 2026-09-04, before I2 can be called done**: iris's
-  texture pipeline asks every device, unconditionally, for
-  `VK_EXT_descriptor_indexing` ("bindless" binding arrays) — and a
-  sourced check says a real share of Android hardware does not have it,
-  not just the emulator's software renderer. See "iris's binding array
-  does not survive real Android hardware" under the iris track for the
-  measurement, the sources, and the recommended fix (generalize the
-  glyph atlas to images, the same way I1 already did for text). Not yet
-  implemented; a design decision to confirm before iris's render core
-  changes.
-- **Next**: decide on the atlas-based image fix above, then **I2** —
-  iris on android-view. **E2** (a transcript in Masonry) can go in
-  parallel in another session.
+- **Resolved, 2026-09-04: iris's binding array does not survive real
+  Android hardware.** iris's texture pipeline used to ask every device,
+  unconditionally, for `VK_EXT_descriptor_indexing` ("bindless" binding
+  arrays), which a real share of Android hardware lacks. It has been
+  rebuilt per TEXTURES.md's "Recommended shape": the glyph atlas is one
+  `texture_2d_array` (a layer per page), a standalone image is its own
+  ordinary `Texture`/`BindGroup`, and `request_device` now asks for no
+  features and no binding-array limits at all. `rigs/gpu-probe`, rewritten
+  to match, confirms `request_device` now succeeds on the emulator's
+  software Vulkan (`EMU_GPU=software`, SwiftShader) — see TEXTURES.md's
+  "Implemented, 2026-09-04" for the exact command and output, and for what
+  was verified (rendering, via `run-headless.sh`) versus what was reasoned
+  through but not separately stress-tested (a real second-atlas-page
+  grow under load). Nothing here has been run on real Android hardware
+  yet, only the emulator; the Android Vulkan Profile 2025 sourcing in
+  "iris's binding array does not survive real Android hardware" below is
+  what stands in for that until I2 gets a device.
+- **Next**: **I2** — iris on android-view. **E2** (a transcript in
+  Masonry) can go in parallel in another session.
 - **Not started**: `client-core`, which is item 1 of the recommendation
   below and does not depend on the framework choice. Nothing has been
   built for it, and it is not one of the numbered boxes — worth picking up
@@ -868,7 +874,12 @@ step measured.
       nightly gates — `portable_simd` (the old glyph compositing) and
       `gen_blocks` (the deleted line iterator). **Eleven left.**
 
-### iris's binding array does not survive real Android hardware (found 2026-09-04)
+### iris's binding array does not survive real Android hardware (found 2026-09-04, resolved 2026-09-04)
+
+**Resolved the same day**: see "Where things stand" above and
+TEXTURES.md's "Implemented, 2026-09-04". The measurement and sourcing
+below are unchanged and are why the fix looks the way it does; nothing
+here needs re-checking on its own account.
 
 Iris asked, of the "unknown number of images" case — a transcript with an
 unbounded number of attached screenshots — whether iris's approach even