Propagate extension tools to sub-agents (nested agent tool availability)

### Describe the feature or problem you'd like to solve

Extension-registered tools (from `.github/extensions/` or user-scoped extensions) are only available to the top-level agent (depth 0) and first-level sub-agents (depth 1) via `onPreToolUse`. Nested sub-agents (depth 2+) cannot access these tools, forcing workarounds like injecting bash/curl instructions via `onPreToolUse` prompt modification.

### Proposed solution

Allow extension tools to propagate to all sub-agent depths automatically (or via an opt-in flag like `propagate: true` in the tool definition). When a sub-agent is spawned via the `task` tool, it should inherit the parent session's extension tools so they can be called natively — just like built-in tools (grep, bash, view) are available at every depth.

This would:
- Eliminate brittle workarounds (prompt injection with CLI/curl fallback instructions)
- Enable consistent tool behavior regardless of agent depth
- Allow users to provide real-time guidance to sub-agents via custom interaction tools or via the existing ask_user tool which is currently not propagated to sub-agents
- Reduce token waste from sub-agents "looking around" when the user could simply answer a question or point them in the right direction

### Example prompts or workflows

1. **Semantic search:** A vector search extension tool provides semantic code search. Sub-agents spawned to analyze search results can't call the tool themselves for follow-up queries — they fall back to grep, degrading result quality.

2. **Approval gates:** A `request_approval` tool requires human sign-off before destructive actions. If a sub-agent spawns another sub-agent that attempts a destructive action, the approval tool is unreachable.

3. **Context injection:** A `get_project_context` tool returns project-specific conventions and constraints. Sub-agents can't access it, so they operate without critical project knowledge.

4. **Multi-step research:** An `explore` sub-agent spawns a `task` sub-agent to run a test. The task sub-agent needs to call a custom notification tool to report progress — but it can't because extension tools don't propagate.

### Additional context

The current workaround is to intercept `task` tool calls via `onPreToolUse`, parse the sub-agent's prompt from `toolArgs`, and append instructions telling the sub-agent to use bash/curl to replicate the tool's behavior. This is:

- **Fragile** — relies on prompt injection that models may ignore or misinterpret
- **Token-expensive** — the injected instructions consume context in every sub-agent
- **Lossy** — bash/curl fallbacks can't replicate rich tool schemas, validation, or structured return values
- **Depth-limited** — even this workaround only works for depth 1→2; deeper nesting requires each level to re-inject instructions

A native solution (tool propagation flag or session-level tool inheritance) would be significantly more robust and would unlock composable multi-agent workflows where extension tools "just work" at any depth.

首先检查 .github/extensions 和 task 工具的 onPreToolUse 处理逻辑，重点关注扩展工具如何在 agent 深度 0 和 1 处暴露。跟踪当前嵌套 agent 的工具可用性，并定义更深层 task 的继承行为，包括提议的 opt-in 传播选项。完成的标准是：包括 ask_user 在内的扩展工具能够在每个嵌套深度一致可用，而无需采用规避 prompt injection 的 workaround。

由索引模型根据 Issue 内容生成。