iris is the framework alone; the app is one crate in app-rust/

Iris: "the organization of the rust rewrite is a mess right now... there
shouldn't be anything related to the app inside of iris. Iris is supposed
to be the UI framework alone." And, on the crate count: "I'm confused why
the app only code needs more than one crate though."

Nine cargo workspaces become three, and the port's project code -- which
sat in five places, four of them inside the framework -- becomes one crate,
`ai-app`, in `app-rust/`:

  client-core                -> app-rust/src/client
  iris/transcript-ui         -> app-rust/src/ui
  iris/transcript-fixture    -> app-rust/src/ui/fixture.rs + tests/ + touch/
  iris/desktop-app           -> app-rust/src/desktop + src/bin_desktop.rs
  iris/android-app           -> app-rust/src/android + android-project/
  android-shell              -> app-rust/src/shell

iris/ keeps core, macro, the iris crate, tabs-ui and rig-input, and now
mentions no session, transcript, setup or server anywhere.

Only two of the old splits had a reason that survived reading. event-model
stays a crate at the repo root because server/ depends on it too, so a
crate is what makes the backend and the app agree by construction. The two
Android .so names looked like a hard constraint -- a package produces one
library artifact -- until P2 turned out to already plan merging those two
Android apps into one; both faces now come out of libai_app.so, picked
apart by features so `--no-default-features --features shell` keeps wgpu,
parley and iris out of the Compose app's APK. docs/RUST.md's "One app
crate" has the rest, including what each remaining feature is for.

DECISIONS.md and SUBAGENTS.md move into docs/ with everything else.

Verified: ./run-tests.sh and `cd iris && cargo test` green, clippy and fmt
clean in all five workspaces, `cargo ndk -t x86_64` links libai_app.so,
build-apk.sh produces an APK that installs and launches on this checkout's
emulator (Gl ... virgl, as expected), and the phone-sized headless
screenshot renders the transcript unchanged.

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

app-rust/touch/flick-120hz.touch

@@ -0,0 +1,21 @@
+# A finger flick the shape Iris's phone delivers one, from
+# docs/bench/iris-phone-v2-2026-09-06.md and docs/IRIS_TODO.md's
+# "From the phone, 2026-09-06, 22:16": at 120Hz a flick reaches the app
+# as DOWN, one or two MOVEs and UP inside a few frames, with the
+# intermediate positions batched inside those MOVEs as historical
+# samples (~4ms apart, the touch digitiser's own rate) rather than
+# arriving as separate events. Each line here is one such sample, which
+# is exactly what `IrisViewPeer::on_touch_event` replays through the
+# sensors one at a time -- so the whole gesture is 20ms and five
+# samples, and the velocity has to come out of *those*.
+#
+# Downward (increasing y) on purpose: the screen opens pinned to the
+# newest end, so a flick the other way has nothing left to scroll to and
+# the fling clamps on its first tick -- a pass that would prove nothing.
+# Coordinates are physical pixels on a 1080x2424 surface.
+0 down 540 1000
+4 move 540 1040
+8 move 540 1086
+12 move 540 1138
+16 move 540 1196
+20 up 540 1196

app-rust/touch/flick-cancelled.touch

@@ -0,0 +1,11 @@
+# `flick-120hz.touch` to the sample, with the platform taking the gesture
+# away instead of the finger lifting -- Android's `ACTION_CANCEL`, which
+# is what the swipe up from the bottom edge to leave the app delivers
+# after its moves. Nothing may follow from it: no tap, no selection and,
+# the one that showed on Iris's phone, no fling.
+0 down 540 1000
+4 move 540 1040
+8 move 540 1086
+12 move 540 1138
+16 move 540 1196
+20 cancel 540 1196

app-rust/touch/long-press.touch

@@ -0,0 +1,11 @@
+# A long-press then a drag across the text: held past LONG_PRESS
+# (500ms) without moving, which is what starts a selection rather than a
+# pan, then dragged sideways so the selection actually covers
+# something. A press alone leaves a collapsed caret and no selected
+# text (`Selection::begin`), which is why this file does not stop at the
+# hold.
+0 down 300 1000
+520 move 300 1000
+560 move 700 1000
+600 move 900 1000
+640 up 900 1000

app-rust/touch/tap.touch

@@ -0,0 +1,5 @@
+# The case the flick had no reason to touch: a press and release in one
+# place, well inside DRAG_SLOP and well under LONG_PRESS. It must be a
+# tap -- no pan, no velocity, nothing moved.
+0 down 540 1000
+80 up 540 1000