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.

Commencez par inspecter .github/extensions et la gestion de onPreToolUse de l’outil task, en vous concentrant sur la manière dont les outils d’extension sont exposés aux profondeurs d’agent 0 et 1. Suivez la disponibilité actuelle des outils pour les agents imbriqués et définissez le comportement d’héritage pour les tâches plus profondes, y compris l’option proposée de propagation opt-in. Le travail est terminé lorsque les outils d’extension, notamment ask_user, sont disponibles de manière cohérente à chaque profondeur imbriquée, sans contournements liés à l’injection de prompts.

Rédigé par le modèle d'indexation à partir du texte de l'issue.