End subagents on the CLI's own task lifecycle, and detect a limit two ways

Subagents were showing "running" long after they had finished. Measured
against 2.1.237 by running a session that launched one Task agent and
reading its stdout: a subagent's lines carry no `stream_event` at all --
they are whole `user`/`assistant` lines with a null `stop_reason` -- and no
`result` line is sent for one. So `ends_a_turn`, which watches for a raw
`message_delta` saying `end_turn`, could never fire for a subagent, and
nothing finished one until its session's process exited.

What the CLI does send is a task lifecycle, as top-level `system` lines:
`task_started` (with the tool_use id), `task_progress`, `task_updated`
(status, naming the task only) and `task_notification` (tool id, status, and
the agent's own summary). `translate_task` keeps the task -> tool mapping,
records the summary as the subagent's closing text -- the run showed its
child lines stop at its last tool_result, so without this a finished
subagent reads as stopping mid-tool -- and ends it. A `completed` update is
deliberately not the end, since its notification carries the summary; any
other terminal status is, because the failure to avoid is a subagent nothing
ever finishes. `ends_a_turn` stays as a second detector and must never be
the only one again. Verified by replaying the captured stream through the
server as a fake CLI: running, prompt, Bash call, output, report, exited.

`finish_all` now reads the directory rather than the live map, which is what
clears the ones already stuck: a subagent left running by an earlier run of
the server is exactly the one this process never touched, so it read
"running" again every time its session was started.

Auto-resume gets the same treatment on its own single point of failure. The
only thing that scheduled a resume was the CLI's error sentence at the end
of a failed turn; the CLI also sends `rate_limit_event` lines saying where
the account stands, and this server ignored them entirely. Both are read
now. Anything that is not an `allowed...` status counts as refused and is
logged if unfamiliar -- being wrong that way costs one question to the usage
meter, which is still what decides whether anything is sent, and being wrong
the other way is the feature silently not existing.

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

SUBAGENTS.md

@@ -52,19 +52,34 @@ transcript is still being written to and its process is the session's to stop.
 2. Every child line is translated by that subagent's own `Translator`
    (one per subagent: tool ids are unique but streaming deltas are by
    content-block index, and parallel subagents interleave).
-3. **The parent's `tool_result` never finishes a subagent.** The Task tool
-   runs in the background by default: the `tool_result` -- "Async agent
-   launched..." -- arrives the moment it *starts*, while the subagent goes
-   on working for however long its own turn takes, sometimes minutes. What
-   ends it is its own turn ending: the raw API's `message_delta` on its
-   stream carrying `stop_reason: "end_turn"` (a `stop_reason` of `tool_use`
-   is the model about to call one, not an end), or a `result` line for its
-   own turn if a future CLI version ever sends one. Either maps to
-   `Status Exited`; the subagent's vocabulary has no `Idle`, so the
-   equivalent event `dispatch` produces for an ordinary session is dropped
-   rather than written. A shipped version of this finished on the
-   `tool_result` instead, which read a running background agent as
-   "finished" with its transcript truncated at the moment it launched.
+3. **What ends a subagent is the CLI's own task lifecycle**, on top-level
+   `system` lines that carry no `parent_tool_use_id`: `task_started`
+   (`task_id`, `tool_use_id`, `is_backgrounded`, the prompt), `task_progress`
+   repeatedly, then `task_updated` (`patch.status`, naming the *task* only)
+   and `task_notification` (`tool_use_id`, `status`, and `summary` -- the
+   agent's own report). `translate_task` keeps the `task_id -> tool_use_id`
+   mapping from the first so the update can be attributed, records the
+   summary as the subagent's closing text, and writes `Status Exited`. A
+   `completed` update is deliberately not the end: its notification carries
+   the summary and would otherwise land after the ending. Any other terminal
+   status ends it from the update, since the failure to avoid is a subagent
+   nothing ever finishes.
+
+   The two rules this replaces were both wrong, in opposite directions. The
+   parent's `tool_result` is not it: a backgrounded Task's arrives at launch
+   ("Async agent launched..."), so ending there truncated a running agent's
+   transcript at the moment it started. Nor is the subagent's own
+   `end_turn`: measured against 2.1.237 on 2026-09-06, **a subagent's lines
+   carry no `stream_event` at all** -- they are whole `user`/`assistant`
+   lines with a null `stop_reason`, no `result` line is sent for one, and the
+   sub's final report never appears as a child line -- so that rule could
+   never fire and every subagent stayed `running` for ever. `ends_a_turn` is
+   kept as a second detector for a dialect that does say either, and must
+   never be the only one again.
+
+   `Status Exited` either way; the subagent's vocabulary has no `Idle`, so
+   the equivalent event `dispatch` produces for an ordinary session is
+   dropped rather than written.
 4. **A child line for a subagent that already finished reopens it**
    (`Status Running`) rather than being dropped: a background Task can be
    sent another message long after its first turn ended, and that is
@@ -72,7 +87,10 @@ transcript is still being written to and its process is the session's to stop.
    `Translator`, just picking back up.
 5. When the parent session's process exits (`Status Exited` on the
    session), every subagent still `Running` gets `Status Exited` too: its
-   process was the parent's.
+   process was the parent's. Read from the directory rather than from the
+   live map, because one left `Running` by a previous run of the server is
+   precisely the one nothing in this process has touched -- and it would
+   otherwise read `running` again every time its session was started.
 
 A subagent that was mid-flight when the backend restarted keeps working:
 the registry reopens the existing transcript on the next child line, and