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>

PLAN.md

@@ -1112,6 +1112,31 @@ with the edge stream; this side uses the authoritative empty/nonempty level and
 its measured size. That size is exposed as `backgroundTasks` in the session row
 and event stream, and is drawn beside the status; background tasks do not become
 subagent cards.
+
+**They are listed in the session's panel, above its subagents** (2026-09-20).
+The count beside the status says how much is going and never what, which left
+"3 bg tasks" as a number with no way to find out what it was about. The list is
+`GET /sessions/{id}/background`: whatever the driver says right now, never
+written to a transcript and never kept here, because it is a measurement of a
+running process and a session with none has nothing to report -- that route
+answers `null` for one, which the panel says in words rather than drawing as an
+empty list. Each entry is an id the reader never sees, the provider's own
+description, and a kind; `description` is optional because Codex names a
+background terminal by a process id, and a card with nothing to say says the
+kind instead of dressing the number up as a name. The section is collapsed to
+its one-line count by default and pushes the subagents down when opened, and it
+is refetched whenever the live `backgroundTasks` count moves, since a card for
+work that has finished is exactly the stale measurement the count was designed
+not to be. A backgrounded subagent appears in both lists: the background one
+because it is running, the subagent one because it has a transcript -- and only
+the subagent card opens, because only it has anything to open.
+
+**An `ambient` task is not background work.** The same level signal carries
+live-update watchers and housekeeping marked `ambient`, which the CLI says
+outright to exclude from activity indicators; counted, they would leave a
+session reading `waiting` with nothing to wait for. They are dropped from the
+count and the list alike.
+
 The driver sends a repeated `initialize` when it adopts a CLI, which prompts a
 full snapshot without restarting the conversation. A parent already recorded as idle or waiting can
 apply it immediately; one adopted mid-turn waits for the result boundary,