canUseTool control channel closes when main query emits result while background Task subagents still running (subagent tools fail with 'AbortError: Stream closed')

## Environment

- `@anthropic-ai/claude-agent-sdk` **0.3.211**
- Node **v22.22.0**
- Windows 11 Pro (10.0.26100)
- SDK embedded in a long-running Node server; sessions created via `query()` with a `canUseTool` callback and hooks (`SubagentStart`/`SubagentStop`, etc.)

## Summary

When the main query emits its `result` message while **background Task subagents are still running**, the permission control channel is torn down. Every subsequent permission-gated tool call made by those subagents fails with:

```
Tool permission request failed: AbortError: Stream closed
```

The subagents themselves keep running (their `SubagentStop` hooks and task notifications still arrive afterward), but they can no longer execute any tool that needs a `canUseTool` decision, so they can only fail or produce degraded output. The host application's `canUseTool` callback is never invoked for these calls — nothing is denied; the request simply has no channel to travel over.

## Reproduction scenario

1. Start a `query()` (streaming input mode) with a `canUseTool` callback that approves tool use.
2. Give the agent a prompt that makes it spawn several **parallel background Task subagents** and then end its turn to wait for them (e.g. "spawn four reviewer subagents, wait for their reports").
3. The main conversation loop finishes its turn → SDK emits `result`.
4. The still-running subagents' subsequent `Bash`/`Read`/etc. calls now fail with `Tool permission request failed: AbortError: Stream closed`.

## Evidence from captured sessions

We analyzed the persisted message logs of 6 affected sessions (an automated code-review pipeline that spawns 4 parallel reviewer subagents per session):

- **Every** `Stream closed` tool failure carries a `parent_tool_use_id` (i.e. is a subagent call); the main agent's own calls never fail this way. Example counts per session (subagent failures / main-agent failures): 10/0, 5/0, 6/0, 6/0, 18/0.
- The first failure consistently appears at the exact point the main agent ends its turn to wait for the subagents.
- The host's `canUseTool` callback is never invoked for the failing calls (no permission events emitted app-side).
- Subagent calls that do **not** require a permission round-trip (e.g. allowed CLI-side by settings rules) continue to succeed after the channel closes — confirming the subagent processes are alive and only the permission relay is gone.
- `system`/`task_notification` messages and `SubagentStop` hooks for those subagents still arrive minutes after the main `result`, on the same (still open) message stream.

## Expected behavior

The `canUseTool` control channel should remain usable as long as any subagent of the session is still running — or at minimum until the query stream itself is closed by the SDK consumer. Alternatively, `result` should not be emitted while background subagents hold pending work (or the docs should state that permission relaying ends at `result`).

## Impact

For autonomous/headless pipelines this is a hard failure mode: the main agent yields to wait for subagents, the session looks "complete" to the host, and the subagents silently lose the ability to run permission-gated tools. In our case review sessions burned ~$2 each across repeated retries without ever posting their output.

## Workaround

Passing the needed tools via `options.allowedTools` (so no `canUseTool` round-trip is required) makes subagents immune to the channel closure. Copying permission allowlist settings into the working directory achieves the same CLI-side.