spawn_task suggestion chips are labeled "running task" from the moment they're created, before the user has chosen to start them

What happened

Calling spawn_task creates a chip and, per its own tool description, explicitly leaves it in a not-yet-started state ("A chip appears for the user; one click spins it off into its own session" — i.e., nothing runs until that click). The tool's own result text confirms this: "Currently pending: task_X ... Continue your current work."

Despite that, the activity badge shows "1 running task" immediately — before any click, before any session or process exists to be running anything.

Why this is a distinct bug (not #91820, #84930, #67404, or #97100)

• #91820 is about what happens after clicking the chip (it injects the prompt in-thread instead of spawning a session).
• #84930 / #97100 are about dismiss/replace state getting stuck after a chip has already been started.
• #67404 is a real, started background task whose completion event is mishandled, leaving a stale "running" count.
• This report is about the label being wrong at creation time, before any of that machinery is even in play — a purely suggested, unstarted, unactioned chip is already counted and displayed as "running."

Reproduced

CLI 2.1.281, desktop app, macOS 15.7.9, 2026-09-25. Exact sequence:

1. Assistant calls spawn_task; tool result explicitly says the task is "pending," not started.
2. Activity badge immediately shows "1 running task."
3. User asks the assistant what's running; assistant confirms (via ListAgents and list_sessions) that nothing is actually running anywhere.
4. Several turns later, the user clicks the chip — only then does any actual work begin (see #91820 for what happens next).

Expected

A merely-suggested, not-yet-started chip should not be counted or labeled as "running" — "1 suggested task" or "1 pending task" would accurately reflect the tool's own stated semantics.

Impact

This is independent of #91820/#84930/#67404/#97100 in a verifiable sense: fixing all four would not fix this. #91820 is about what happens on click; #84930/#97100 are about dismiss/replace state after a chip has been started; #67404 is a started task's completion event getting lost. This bug fires before any of that machinery runs — a chip that has never been clicked, in a session where no work has ever begun, is already counted and labeled "running." The mislabeling isn't a side effect of any of those mechanisms; it's wrong at the moment of creation, independent of what happens next. An operator reading the badge in its ordinary sense — "something is executing right now" — is misled with zero required action on their part, which is a stronger and earlier-triggering version of the same trust problem those other reports describe, not a symptom of it.