No way to cancel/kill a dispatched background agent — a stuck one runs indefinitely and silently burns spend #2822

The SDK exposes a way to dispatch a background agent (task delegation with mode: "background") and to message it (write_agent), but there is no corresponding way to forcibly cancel/terminate one. When a background agent gets stuck (stalled mid-tool-call, or ignores a "stop" instruction sent via the message channel), there is no supported mechanism to kill it. It keeps running — and consuming spend — indefinitely.

Environment
@github/copilot-sdk-darwin-arm64: 1.0.15-unstable.35393089353.gfc44743
VS Code: 1.139.1 (commit 04c0d99f4fb0d8afe6ce4f0c58e31e183ac3e4b1)
OS: macOS 26.7 (Build 25G229), arm64

Steps to reproduce
Dispatch a background agent via the task-delegation tool (mode: "background").
Have it get stuck (in our case: it completed its task, then received a follow-up instruction, misinterpreted it, and entered a state where its tool-call counter stopped incrementing entirely).
Send it a message asking it to stop (via the message/write channel). It acknowledges in some cases but continues running regardless.
Attempt to terminate it through every other surface available to the host integration (in our case: a generic process-stop tool unrelated to agent lifecycle). No effect.
Observe: the agent's status remains "running" indefinitely (ours ran 4+ hours with its tool-call count frozen) with no way to confirm whether it will ever stop, and no way to force it to.

Expected behavior
A host application integrating the SDK should have a supported, reliable way to forcibly cancel/terminate a dispatched background agent — distinct from asking it nicely via a message — that reliably stops execution and halts further spend.

Actual behavior
No such capability is exposed. The only levers available (messaging the agent to ask it to stop) are advisory, not enforced, and can be silently ignored or missed if the agent is in a stuck state rather than actively processing messages.

Impact
This is a real cost-control gap: a single misbehaving background agent can run unbounded and there is no circuit breaker. For any production integration this is a significant risk, not just an inconvenience.

Related
#2043 is related (a supported allow-list to prevent certain built-in sub-agents from running at all) but addresses a different problem — preventing an agent from starting, not stopping one that's already running and stuck.

Suggested fix
Expose a cancel_agent/terminate_agent-equivalent API (mirroring the existing dispatch/message/list APIs) that forcibly tears down a background agent's execution context, independent of whether the agent itself is responsive to messages.