[FEATURE] Mark a subagent killed by a usage limit as resumable, and keep it listed after a session restart

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

When a usage limit kills a background subagent, the work looks lost. It isn't: `SendMessage` to the dead agent's id resumes it from its transcript, with its original instructions. But nothing tells the user or the orchestrating model that, so the natural move is to spawn a fresh agent and redo the work.

A session restart makes it worse. After `/login` (or anything else that starts a new session id), `ListAgents` no longer lists the old agents and their `tasks/.output` files are gone. The only way back is to have written the id down, or to dig it out of `~/.claude/projects///subagents/agent-.jsonl`. With that id, `SendMessage` still resumes the agent across sessions.

What we observed (v2.1.270, 2026-09-14): a code-review orchestrator and its 6 finder subagents all died on a usage limit. The orchestrating model spawned a fresh review instead of resuming. Later, from a new session id, we sent `SendMessage` to the old orchestrator's id. It replied "Resuming agent", then resumed its own 6 finders by id: all 6 came back with their original instructions, none was re-spawned, and the 2 that had finished before the limit kept their results. In our one comparison, the fresh re-run reported 4 findings for ~205k tokens, and the resumed run reported 10 confirmed findings for ~166k.

### Proposed Solution

1. When a subagent dies on a usage limit, the task notification says so, and says the agent can be resumed with `SendMessage` to its id once the limit resets.
2. `ListAgents` and `/tasks` keep listing agents that a limit killed in a recent earlier session of the same project, marked e.g. "stopped (usage limit) — resumable", so a restart doesn't hide them.
3. Optional: when auto-continue fires at reset (#89263), resume the limit-killed subagents as well. Resuming the parent is enough if it is told to resume its children.

### Alternative Solutions

Our workaround today: record every dispatched agent id in a ledger file. After a limit, `SendMessage` the parent and tell it to resume its children by id. It works, but only for users who already know resuming is possible.

### Priority

High - Significant impact on productivity

### Feature Category

Interactive mode (TUI)

### Use Case Example

An orchestrator dispatches implementer, reviewer and finder subagents in the background for a multi-hour plan. A usage limit kills several of them mid-task. After the reset, the notification or `ListAgents` shows them as resumable, and the orchestrator sends each one a `SendMessage` to continue. Today it spawns replacements and redoes their work instead.

### Additional Context

Related, but not the same request:
- #89263: auto-continue never arms when a limit kills only background subagents.
- #90520: resuming a *completed* subagent later fails with "No transcript found".
- #76602: the panel for a resumed subagent renders its transcript garbled.

Start by tracing the ListAgents and /tasks entry points, then follow how usage-limit termination and session changes affect SendMessage. Inspect the tasks/.output and project session subagents/agent-.jsonl paths described in the issue. Done means limit-killed agents remain discoverable across a restart, are clearly marked resumable, and can be resumed by id.

Escrito por el modelo de indexación a partir del texto del issue.