[BUG] Subagents (Task/Agent tool) die silently on spend/usage limit hit, with no partial-result handoff or wait-for-reset behavior

Description:
When a dispatched subagent (via the Agent/Task tool) hits a spend or usage limit mid-run — this happens both on the monthly account-wide spend cap and on regular subscription usage limits — it terminates abruptly with no graceful handling:

• No partial output or state is returned to the orchestrating session — the work done up to that point is lost, not handed back.
• The failure surfaces only as a background notification ("You've hit your monthly spend limit" / usage limit reached), with no distinction from any other subagent failure mode, so the orchestrator can't tell "limit hit" apart from "agent bug" without re-reading raw output.
• Critically, even when the limit is a subscription usage limit that resets on a known schedule (i.e., the kind where a user would normally just "wait for reset"), the subagent does NOT wait and resume — it is killed outright. There's no pause/retry-after-reset behavior; the only option is a full re-dispatch from scratch once the window resets, discarding all prior progress.
• Waiting for the reset doesn't reliably fix it either: re-dispatching the same task after the limit had already reset ran into the exact same failure again, sending the task back to square one a second time. This makes the limit non-deterministic from the user's side — there's no reliable signal for "it's actually safe to retry now."
• If the subagent's task had side effects (e.g., writing to a live database, creating test data), those side effects are NOT rolled back or flagged — the parent session has no way to know work was left half-done in an external system until it manually re-inspects state.

Reproduction: Dispatch any Task/Agent subagent for a moderately long task (Claude Code CLI) on an account near either its monthly spend cap or its subscription usage limit. The agent dies mid-run; no partial transcript, no wait-for-reset/auto-resume, no rollback of external side effects, no reset-time estimate — and even a subsequent retry after the limit has reset can hit the same failure again.

Expected: At minimum — (1) surface remaining-budget/reset-time info before dispatch so the failure is predictable, not silent, (2) for limits with a known reset schedule, pause and auto-resume the subagent after reset instead of killing it outright, and (3) return whatever partial output/transcript the subagent produced before termination, so the orchestrator isn't fully blind to what happened.

Impact: This isn't just a one-time loss — because each termination discards all prior progress, hitting the limit repeatedly forces the same subagent task to be re-dispatched from scratch every time, including after waiting for a reset that should have cleared it. In our case the same verification task hit the limit three separate times (one of them after an intentional wait-for-reset), so the same work had to be re-run three times over, burning real token/usage budget on redundant re-execution of work that had already been done and shouldn't have needed to be redone at all.