statusline: an agents segment — which subagents are running, on which model

[dcotelo]

Problem

The statusline shows the account, the model, the directory, the branch, and the
context and usage bars — everything about the session except what it is
currently doing. When a session dispatches subagents, nothing on the line says
how many are running, which ones, or what model each is on. That is the one
piece that keeps a second statusline on screen alongside cprof's.

Proposed behavior

An agents segment, one line per agent, in this shape:

⚑ work │ [Opus 5 (1M context)] │ cprof git:(main*)
Context ████░░░░░░ 39% │ Usage ██░░░░░░░░ 18% (resets in 4h 2m)
✓ claude-code-guide [haiku-4.5]: Check subagent lifecycle hooks (3s)

Five fields: a status glyph, the agent's name, its model, its task, and how long
it has been running. Finished agents stay visible for a while — the glyph
carries the distinction between running, done and failed — because a subagent
that finished ten seconds ago is still the thing you are waiting to read.

Alternatives considered

• SubagentStart/SubagentStop hooks. They exist, and were rejected: they
  only fire for sessions running this plugin, and a missed stop leaves a ghost
  agent on the line forever. A statusline that lies is worse than one that
  omits.
• Shelling out to something that already knows. Nothing on the machine
  exposes this as a queryable surface; the transcript is the source of truth.
• Leaving it to another statusline and composing. Works today, and is what
  the docs' composition recipe is for — this issue exists because the goal is
  for cprof alone to be sufficient.

Additional context

Surface: statusline. Needs no network and no git.

Data source, already ruled: an incremental parse of the session transcript,
with a per-session cache keyed on inode and byte offset, so each tick reads only
what was appended. The statusline runs every few seconds and must never add
latency; re-reading a 36MB transcript per tick is not an option.

First task is a spike, not code. Three questions have to be answered from a
real transcript before this can be specced, and a probe run today could not
answer any of them: this project's six transcripts contain no subagent entries
at all — no isSidechain markers, no Task tool_use inputs — so where subagent
activity is recorded, and in what shape, is currently unknown.

1. Is the subagent's model recorded anywhere readable? The target format
   shows [haiku-4.5], and if the transcript does not carry it, the field has
   to be dropped or sourced elsewhere — which changes the format the whole
   segment is designed around.
2. How is a finished agent distinguished from a running one, and how is a
   failure distinguished from a success? The glyph depends on it.
3. How long should a finished entry live on the line, and does that need to be
   configurable?

Until the spike answers 1, this is a design question rather than an
implementation task — hence size:xl.

Depends on nothing else, but note #34 (weekly bar) introduces conditional
rendering — a listed segment that produces nothing must make its line vanish —
which agents needs too. Whichever lands first should build it properly.