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>

SUBAGENTS.md

@@ -77,9 +77,28 @@ transcript is still being written to and its process is the session's to stop.
    kept as a second detector for a dialect that does say either, and must
    never be the only one again.
 
-   `Status Exited` either way; the subagent's vocabulary has no `Idle`, so
-   the equivalent event `dispatch` produces for an ordinary session is
-   dropped rather than written.
+   `Status Exited` either way; the subagent's vocabulary has no `Idle` or
+   `Waiting`, so the end-of-turn status `dispatch` produces for an ordinary
+   session is dropped rather than written.
+
+   **The ending is also reported to the parent** (2026-09-06), as
+   `Event::TaskNote { about, title, status, summary }`: the notification is a
+   message the session received, and the turn it wakes up and runs would
+   otherwise begin with nothing in front of it -- which drew two replies as
+   one paragraph. Reported once however many of the two lifecycle shapes
+   arrive; the `task_id -> tool_use_id` entry is removed as it is reported,
+   which is what says the first one got there. See PLAN.md's "A task
+   reporting back".
+
+   **While any task is outstanding the session's turn ends in
+   `Status Waiting` rather than `Idle`** -- the same `tasks` map, asked
+   whether it is empty. `Idle` means "waiting for a person", and a session
+   with a backgrounded subagent is not doing that.
+
+   **A limit the account hits inside a subagent is hoisted to the session**
+   as well as recorded here, because `resume.rs` can only schedule against a
+   session, and a background subagent outliving its parent's turn is the
+   ordinary case -- see PLAN.md's "A limit a subagent hits is the session's".
 4. **A child line for a subagent that already finished reopens it**
    (`Status Running`) rather than being dropped: a background Task can be
    sent another message long after its first turn ended, and that is
@@ -145,7 +164,9 @@ list and the delete cannot disagree about it.
 
 `status` is the transcript's last `Status` event, serialised like a session's
 (`running`, `exited`), except that a subagent whose session is not itself
-running cannot be running: the list answers `unknown` for that one. The
+running cannot be running: the list answers `unknown` for that one. A
+subagent never reports `waiting`: that is a session's word for having
+outstanding work of its own, and a subagent has none. The
 phone words these as *running*, *finished* and *unknown* on the subcard.
 
 The count on `SessionInfo` is a directory listing, so the list stays cheap.