No way to scope an externally-registered tool away from sub-agents

An SDK consumer registers external tools via `SessionConfig.tools` / `ResumeSessionConfig.tools`. Those tools reach the default agent **and** are inherited by sub-agent runs, including built-in ones (`task`, `explore`, …). There is no supported way to express "this tool is for the top-level agent only."

## The existing controls are asymmetric

- `DefaultAgentConfig.excluded_tools` hides a tool from the default agent *while keeping it available to sub-agents* — precisely the opposite of what's needed. (Its own doc comment says so: "hide tools from the default agent while keeping them available to custom sub-agents that list them in their `CustomAgentConfig::tools`".)
- `CustomAgentConfig.tools` is a per-custom-agent allowlist, so it only constrains agents the consumer defines. Built-in sub-agents can't be reached this way.
- `excluded_builtin_agents` removes the sub-agent outright — far too coarse, and it disables capability the consumer still wants.

## Why this is general

Many externally-registered tools are either:

1. **UI-bound** — they drive a picker, a canvas, an editor, or another foreground surface that only exists for the conversation the user is actually looking at. A background sub-agent has nothing to drive.
2. **Acting with the user's authority in a third-party system** — posting messages, filing tickets, sending mail, spending money. Autonomous invocation from a delegated worker is the wrong default.

Neither of those is specific to one embedder; both follow from the tool being executed outside the agent loop, on behalf of a user who is present in exactly one conversation.

## Ask

A way to declare this at registration. Two shapes seem plausible:

- A field on `Tool`, e.g. `availability`: `session` (default) | `primary-agent-only`.
- A `DefaultAgentConfig`-symmetric sub-agent config carrying `excluded_tools`.

The `Tool`-level field seems stronger: the constraint belongs to the tool rather than to one agent's configuration, so it keeps holding as new built-in agents are added, and a consumer registering a tool doesn't have to enumerate the agent set to protect it.

## Current workaround

Refusing the invocation after the fact — the host answers the tool call with a failure instead of executing it. That works, but it costs a model turn, hands the model an error it may retry against, and gives no way to express that the tool simply isn't available in that context. The tool stays in the sub-agent's tool list either way.

Bắt đầu bằng cách lần theo SessionConfig.tools và ResumeSessionConfig.tools đến Tool, DefaultAgentConfig, CustomAgentConfig và phần thiết lập các sub-agent tích hợp sẵn. So sánh các thiết kế được đề xuất về khả dụng ở cấp Tool và loại trừ ở cấp agent; được xem là hoàn tất khi một công cụ đã đăng ký có thể tiếp tục khả dụng cho agent chính nhưng không khả dụng cho các sub-agent tích hợp sẵn mà không cần xóa các agent đó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.