List a session's background tasks above its subagents

The count beside the status said how much work was going and never what,
so "3 bg tasks" was a number with no way to find out what it was about.

Drivers now report the tasks themselves rather than a size:
`Driver::background_tasks` returns `Vec<BackgroundTask>` -- id, the
provider's own description, and a kind -- served by
`GET /sessions/{id}/background`. It is runtime state, never persisted,
and `null` is "nobody has said", which is what a session with no process
answers and what the panel says in words rather than drawing as an empty
list. `description` is optional because Codex names a background terminal
by a process id, and a number drawn as a name is worse than admitting
there is none.

Claude's `background_tasks_changed` entries turn out to be objects
carrying `task_id`, `task_type` and `description`, so each is read rather
than counted -- and an `ambient` one is now dropped from the list and the
count alike, on the CLI's own instruction: a live-update watcher is not
activity, and counting one left a session reading `waiting` with nothing
to wait for.

The phone draws them in the right-hand panel above the subagents,
collapsed to "2 bg tasks running" and pushing the subagents down when
opened. Both lists are items of one lazy column, so neither can run off
the panel, and the section is refetched whenever the live count moves --
a card for work that has finished is exactly the stale measurement the
count exists not to be.

Verified against the real Claude CLI (2.1.261): a backgrounded `sleep 120`
came back as `{"id":"br16327wr","description":"Sleep for 120 seconds",
"kind":"command"}`, and on the emulator against the echo rig the section
appeared, expanded, and dropped a card as its task finished.

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

SUBAGENTS.md

@@ -94,10 +94,15 @@ transcript is still being written to and its process is the session's to stop.
    Since Claude Code 2.1.261, `background_tasks_changed { tasks: [...] }` is
    the authoritative level beside those edges: its set replaces the previous
    set, so a missed terminal edge cannot leave a subagent running forever. Its
-   ids are deliberately not correlated with the edge stream; the useful claims
-   here are whether the set is empty and its measured size. The session API and
-   stream expose that size as `backgroundTasks`, which the phone draws beside
-   the status without pretending those tasks are subagents. The edges still
+   ids are deliberately not correlated with the edge stream; what is read off
+   each entry is its own description and kind, and what is read off the set is
+   whether it is empty and how large. The session API and stream expose that
+   size as `backgroundTasks`, which the phone draws beside the status, and
+   `GET /sessions/{id}/background` serves the entries themselves -- listed in
+   the session's panel *above* the subagents and never as subagent cards. An
+   `ambient` entry is excluded from both, on the CLI's own instruction: a
+   live-update watcher is not activity. A backgrounded subagent is legitimately
+   in both lists, since it is both running and a transcript. The edges still
    carry mapping, outcome and closing summary. On adoption the driver sends a repeated `initialize`,
    which makes a current CLI send the full set; an older CLI accepts it and sends no level,
    leaving the edge-based path unchanged. A snapshot is reconciled immediately