Custom Invocation Context propogation when using AgentTool

**Is your feature request related to a problem? Please describe.**

When using agents as tools via AgentTool, there's currently no way to propagate custom InvocationContext extensions from the parent agent to the sub-agent. The AgentTool class always creates a new Runner with standard ADK services (InMemorySessionService, InMemoryMemoryService, etc.), which means any custom services or context extensions in the parent agent's execution environment are lost.

This creates a significant limitation for applications that need to inject custom services (like database connections, external APIs, or application-specific state) into their agent execution pipeline. Currently, developers must resort to workarounds like service locator patterns or global state, which breaks the clean dependency injection model that the ADK's context system is designed to provide.

**Describe the solution you'd like**

Add support for propagating custom InvocationContext types and custom services from parent agents to sub-agents when using AgentTool. This could be implemented in several ways:

Option 1: Allow AgentTool to accept an optional runner_factory parameter that can create a custom Runner with the appropriate services:

AgentTool(agent=my_agent, runner_factory=lambda: CustomRunner(...))
Option 2: Modify AgentTool to inherit services from the parent ToolContext's InvocationContext, preserving custom services and context types when creating the sub-agent's runner.

Option 3: Add a context_propagation_mode parameter to AgentTool that controls whether to use isolated services (current behavior) or inherit from parent context.

The preferred solution would be Option 2, as it maintains backward compatibility while enabling custom context propagation by default.

**Describe alternatives you've considered**

Service Locator Pattern: Using a global service registry that tools can access, but this breaks the clean dependency injection model and makes testing more difficult.

Callback-based Injection: Injecting services through agent callbacks, but this requires reimplementing tool logic in callbacks, which is cumbersome and defeats the purpose of having separate tool functions.

Tool Wrapper Functions: Creating wrapper functions for each tool that need custom services, but this creates significant code duplication and maintenance overhead.

Modifying Tool Functions: Adding fallback logic to each tool to access services through multiple methods, but this pollutes the tool implementation with infrastructure concerns.

**Additional context**

This limitation particularly affects complex multi-agent applications that need to maintain consistent access to application-specific services (databases, external APIs, configuration, etc.) across the entire agent execution tree. The current architecture works well for simple, isolated agent tools but breaks down when building sophisticated applications that require dependency injection.

The ADK's InvocationContext system is well-designed for this kind of service injection, but the AgentTool implementation doesn't respect custom context extensions, creating an architectural inconsistency in the framework.