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>

AGENTS.md

@@ -138,7 +138,8 @@ Module-by-module intent is in PLAN.md's "Backend layout".
 - `app/` — the Compose app, package `com.example.aiapp`, label "AI Sessions".
   `AppRoot.kt` is the navigation `when`; `SidePanels.kt` the one drag that
   slides the whole main screen over a session from the left (`MainPanel.kt`)
-  and its subagents over it from the right (`SubagentPanel.kt`), both keeping
+  and what it has running beside the turn -- its background tasks over its
+  subagents (`BackgroundTasks.kt`, `SubagentPanel.kt`) -- from the right, both keeping
   the session composed underneath; `MainScreen.kt` the root's three tabs
   (sessions, import, machines); `MachineModels.kt` the models on one machine
   and the downloads putting them there, drawn inside `ProviderScreen.kt` for a
@@ -361,7 +362,12 @@ written, and the fold uses that same predicate to decide a reply is settled.
   a missed ending edge. Its array size is also the measured `backgroundTasks`
   count exposed on the session row and event stream; the phone draws a nonzero
   count beside the status rather than deriving one from `waiting` or from the
-  subagent directory. An adopted CLI is sent a repeated `initialize` to ask
+  subagent directory. **What those tasks are is `GET /sessions/{id}/background`**,
+  listed in the session's right panel above the subagents: runtime state, so it
+  is never persisted and `null` -- not an empty list -- is what a session with
+  no process answers. An `ambient` task is dropped from both the list and the
+  count, on the CLI's own instruction: a live-update watcher is not activity,
+  and counting one leaves a session `waiting` for ever. An adopted CLI is sent a repeated `initialize` to ask
   for the current set. Reconcile only between turns or at a result boundary:
   a foreground agent is legitimately absent from a background-only snapshot.
   Older CLIs still need both edge sources: `open_tasks` knows about a