feat: support abort parameter in runner, agent, model, tool and processors

[kalenkevich]

Please ensure you have read the contribution guide before creating a pull request.

Description of Change

This PR implements comprehensive support for AbortSignal across the core components of the ADK TS. This allows for the graceful cancellation of long-running agent operations, streaming model responses, and tool executions, resolving issues with unhandled promise rejections or runaway executions when a task is no longer needed.

Rationale

Allowing execution to be aborted at any level is critical for resource management and user experience. With these changes, a cancellation triggered by a user or timeout will propagate down to stop active LLM generations and inform running tools, preventing wasted resources and unhandled promise rejections.

Runner

• Runner: Added abortSignal to parameters for runAsync. Added guards checking abortSignal.aborted at critical lifecycle points (e.g., before session fetching, after plugin executions, and within event streaming loops) to ensure quick termination.

Agents

• InvocationContext: Added optional abortSignal to InvocationContextParams. Registered an event listener on the signal to automatically set this.endInvocation = true when triggered.
• LlmAgent: Added checks for context.abortSignal?.aborted within the main execution loops and before yielding events. Passed the abort signal down to the model call.
• LoopAgent & ParallelAgent: Added abort checks within their iteration/merging loops to terminate sub-agent execution early if requested.

Models

• BaseLlm: Updated generateContentAsync signature to accept an optional abortSignal.
• Gemini (Google LLM): Propagated the abortSignal to the underlying Google GenAI SDK by setting llmRequest.config.abortSignal.

Tools

• AgentTool: Passed the toolContext.abortSignal into the sub-agent runner and added early return checks.
• MCPTool: Passed the abort signal to the MCP client's callTool method options.

Other

• Increased timeout in stream_test.ts to account for potential latency during testing.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Summary of passed npm test results:

• core/test/runner/streaming_runner_test.ts passed with 13 tests.
• Tests in llm_agent_test.ts and google_llm_test.ts were also verified to contain the new abort logic

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.