Background task notifications stay queued until the next user message in SDK streaming mode

### What happened

With `@anthropic-ai/claude-agent-sdk` 0.3.220 driven in streaming input mode (the consumer here is VS Code's agent host), background `Task` subagents finish and their notifications are enqueued promptly, but the queue is not drained until the user happens to send an unrelated message. The main agent is never re-prompted, so it keeps believing the work is still running and never reports the results.

Three background subagents were spawned. From the session transcript, all times UTC:

| Time | Entry |
|---|---|
| 19:25:34 | subagent 1 transcript ends |
| 19:25:35 | `{"type":"queue-operation","operation":"enqueue"}` carrying its `` |
| 19:27:03 | subagent 2 transcript ends |
| 19:27:05 | enqueued |
| 19:28:53 | subagent 3 transcript ends |
| 19:28:55 | enqueued |
| 19:32:16 | user sends an unrelated message |
| 19:32:34 | notification 1 finally appears as a `"type":"user"` entry |
| 19:32:40 | notifications 2 and 3 `"operation":"remove"` after being folded in as attachments |

So the notifications sat queued for between 3.5 and 7 minutes. In the meantime the assistant stated that the agents were still running, which was true when written and then stayed stale. The parent turn remained open for the whole period and only ended at 19:32:16, at the instant the user's message arrived.

### What I expected

The session to wake when the background work settled. The SDK's own types describe this: `HookInput.background_tasks` is documented as letting hooks distinguish "session is done" from "session is paused waiting for background work to wake it", `SDKControlInterruptRequest.still_queued` refers to "the drain loop, which starts the next queued turn immediately", and the prompt-source field lists task notifications among machine-injected `system` turns. All of that reads as though the CLI injects the notification as a turn on its own.

For contrast, in interactive Claude Code the same notifications go from queued to delivered in roughly half a second without any user message.

### Notes

I could not narrow this further because the CLI ships as a compiled binary, so I cannot see what gates the drain. I also could not find a consumer-facing option that controls it. If the intent is that an SDK consumer must submit something to drain the queue, that would be worth documenting on `SDKTaskNotificationMessage`, since a consumer that treats the notification as a UI-only signal (which is what VS Code does today) produces exactly this stall.

### Environment

- `@anthropic-ai/claude-agent-sdk` 0.3.220, `linux-arm64`
- Consumer: VS Code agent host, streaming input mode
- Dev container on Windows 11 ARM64

*AI disclosure: this issue and the related investigation were written with the assistance of AI.*

Start by reproducing streaming input mode with background Task subagents and inspect the notification queue and drain-loop behavior described in the issue. Verify that a settled background task wakes the parent without a user message, and add or run a regression test covering queued task notifications and their delivery.

索引モデルが issue の本文から書いたものです。