Never run two turns into one, and say when a session waits on its own work

A turn started by something with no row of its own -- a subagent reporting
back, a peer message the CLI only owns up to at the end -- met the previous
reply with nothing between it, and the fold grew that reply rather than
starting a new one. Two answers were drawn as one paragraph, running together
mid-sentence with not even a space between them. The fold now refuses to grow
a settled reply, and `joinPages` carries the same rule across a page boundary.

The other half is the row. `Event::TaskNote` records a background task
reporting back -- a subagent that finished, or a backgrounded command -- with
its title, how it ended and what it said; `TaskNoteRow` draws it as a card,
since somebody said this, and its own row rather than an update to the Task
call's, which is above everything the session has said since. Reported once
however many of the CLI's two lifecycle shapes arrive.

`SessionStatus::Waiting` is a session whose own turn is over while work it
started is not. `Idle` means "waiting for a person" and this means the
opposite, so reporting it as idle sent a "finished" notification at the one
moment that was untrue. Drawn as "waiting" in `waitingColor`; the queue and
the held-command boundary release on either end-of-turn status, so a message
sent while a subagent runs is not held until it finishes.

And a usage limit the account hits inside a subagent now reaches the session
as well as the subagent's transcript. `resume.rs` can only schedule against a
session, and a background Task outliving its parent's turn is the ordinary
case, so auto-resume was doing nothing at all for it.

The status word and its colour were two `when`s on two screens, and the second
missed `waiting` silently; they are `sessionStatusWord`/`sessionStatusColour`
now. Echo's `/subagent n` reproduces the whole shape, staggered a second
apart. Verified on the emulator against the sandbox: 169 server tests, ktfmt,
clippy, rustfmt, Android lint and the JVM unit tests all clean.

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

app/androidApp/src/main/kotlin/com/example/aiapp/Theme.kt

@@ -134,6 +134,20 @@ val clearedColor: Color
 val awaitingColor: Color
     @Composable get() = Mocha.Peach
 
+/**
+ * Waiting on itself: the session's turn is over, but a subagent or a backgrounded command it
+ * started is still going, and it will speak again with nobody having typed anything.
+ *
+ * Its own colour rather than [awaitingColor], which is the opposite state -- that one means the
+ * reader has something to do, and this one means they specifically do not. Not [runningColor]
+ * either: nothing is being written, and a green "running" on a session that will say nothing for
+ * ten minutes is the wrong promise. Blue for the same reason [commandColor] is blue -- not stuck,
+ * but not replying to you either -- and a different blue because that one is the session acting on
+ * itself rather than getting on with what was asked.
+ */
+val waitingColor: Color
+    @Composable get() = Mocha.Sky
+
 /** Approaching a limit -- still fine, worth seeing. */
 val warningColor: Color
     @Composable get() = Mocha.Yellow