Select any of the transcript, and take a queued message back

Two things a reader could not do to what is on screen.

**Selection.** Nothing in the transcript was selectable at all, so a
command, a path or an error message could be read and not copied. One
`SelectionContainer` around the whole list rather than one per row: a
transcript is one body of text to a reader, and a selection has to be able
to run from a reply into the tool output under it. Per row it also could
not, and whatever was drawn without a container would have been silently
unselectable -- a state nothing on screen reports. Rows keep their tap
handlers; checked on the emulator that expanding a tool call, scrolling and
flinging are all unaffected, since a selection is a long press.

**Taking a message back.** A message sent into a running turn sits as a
bubble waiting to be read, and there was no way to change your mind: it is
tappable now, and the server answers `POST /sessions/{id}/unqueue`.

The answer has three states, and the middle one is the point. Claude's
driver writes a steer into the CLI's stdin the instant it arrives -- that
is what makes it reach the model at the next tool boundary rather than at
the end of the turn, and it was measured -- so the line is already gone and
`AlreadySent` is the only honest answer it can give. Holding the write
until a boundary would make the drop real and cost a steer one model call,
which is the latency the immediate write exists to remove; rejected on that
trade, with the reasoning in PLAN.md. The refusal is drawn on the bubble
that was pressed rather than in the error row under the header, a screen
away from it.

Where a driver really does hold its queue -- echo today -- the message goes
for good, and it goes as an `Event::MessageDropped` rather than as a return
value: every device watching the session loses the bubble, and a phone that
reconnects and replays the `messageQueued` does not put back one that was
cancelled with nothing left to resolve it.

server/src/session/echo.rs

@@ -53,7 +53,7 @@ use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
 use std::sync::{Arc, Mutex};
 use std::time::Duration;
 
-use super::driver::{Driver, Event, EventSink, ImageRef, QuestionOption, SessionStatus};
+use super::driver::{Driver, Event, EventSink, ImageRef, QuestionOption, SessionStatus, Unqueued};
 
 /// Delay between streamed deltas -- long enough that streaming is visibly
 /// streaming in the UI, short enough that tests waiting on a full turn
@@ -796,6 +796,23 @@ impl Driver for EchoDriver {
         !self.busy.load(Ordering::SeqCst)
     }
 
+    /// Really droppable, which is what makes this the rig for the phone's
+    /// side of it: the held message is this driver's own and nothing has
+    /// been written anywhere, so a tap here exercises the whole path
+    /// through to the bubble disappearing on every device. The Claude
+    /// driver can only ever refuse -- see its own `unqueue` -- so it
+    /// cannot exercise the case where the drop succeeds.
+    fn unqueue(&self, id: &str) -> Unqueued {
+        let mut queued = self.queued.lock().unwrap();
+        let Some(at) = queued.iter().position(|(waiting, ..)| waiting == id) else {
+            return Unqueued::Unknown;
+        };
+        queued.remove(at);
+        drop(queued);
+        self.emit(Event::MessageDropped { id: id.to_string() });
+        Unqueued::Dropped
+    }
+
     fn send_user_message(&self, text: String, images: Vec<ImageRef>) {
         // Announced, because this is a message: every driver owes exactly
         // one `MessageTaken` per message, and one that quietly vanishes