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.

Bắt đầu bằng việc kiểm tra .github/extensions và cách xử lý onPreToolUse của công cụ task, tập trung vào cách các công cụ extension được cung cấp ở độ sâu agent 0 và 1. Theo dõi khả năng cung cấp công cụ hiện tại cho các agent lồng nhau và xác định hành vi kế thừa cho các task sâu hơn, bao gồm tùy chọn lan truyền opt-in được đề xuất. Hoàn thành nghĩa là các công cụ extension, bao gồm ask_user, đều khả dụng nhất quán ở mọi độ sâu lồng nhau mà không cần workaround để đối phó với prompt injection.

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