Found docs updates needed from ADK python release v2.7.1 to v2.8.0

Reference comparison: https://github.com/google/adk-python/compare/v2.7.1...v2.8.0

## Feature Changes

### 1. **Global override for `max_llm_calls`**

**Doc file**: docs/runtime/runconfig.md

**Current state**:
> - `max_llm_calls`: Caps the total number of LLM calls per run (default: 500). Set to 0 or negative for unlimited calls, though this is not recommended for production. Values at or above `sys.maxsize` raises an error.

**Proposed Change**:
> - `max_llm_calls`: Caps the total number of LLM calls per run (default: 500). This limit can be overridden globally by setting the `ADK_MAX_LLM_CALLS` environment variable. Set to 0 or negative for unlimited calls, though this is not recommended for production. Values at or above `sys.maxsize` raises an error.

**Reasoning**:
The v2.8.0 release introduces `ADK_MAX_LLM_CALLS` as a way to globally override the default `max_llm_calls` value, allowing users to configure limits dynamically.

**Reference**: src/google/adk/agents/run_config.py

### 2. **Task mode and native auth for Remote A2A Agent**

**Doc file**: docs/a2a/quickstart-consuming.md

**Current state**:
> The main agent uses the `RemoteA2aAgent` class to consume the remote agent (`prime_agent` in our example). As you can see below, `RemoteA2aAgent` requires the `name` and an `agent_card`, which can be an `AgentCard` object, a URL (as in the example below), or a path to a local agent card file; the `description` field is optional and defaults to an empty string.

**Proposed Change**:
> The main agent uses the `RemoteA2aAgent` class to consume the remote agent (`prime_agent` in our example). As you can see below, `RemoteA2aAgent` requires the `name` and an `agent_card`, which can be an `AgentCard` object, a URL (as in the example below), or a path to a local agent card file; the `description` field is optional and defaults to an empty string.
>
> You can also pass authentication parameters (`auth_scheme`, `auth_credential`, and `credential_key`) to natively authenticate calls to the remote agent. Additionally, you can specify `mode="task"` to run the remote agent as a task sub-agent. In task mode, the sub-agent owns the conversation across multiple turns and only returns control when the remote A2A task reaches a terminal state via the `finish_task` tool.

**Reasoning**:
The v2.8.0 release adds support for Task mode delegation (`mode="task"`) in Remote A2A Agents, allowing them to manage multiple turns until explicitly finished. It also adds built-in auth parameters (`auth_scheme`, `auth_credential`) to directly authenticate the agent rather than requiring custom httpx clients or interceptors.

**Reference**: src/google/adk/agents/remote_a2a_agent.py

### 3. **Cloud Build private worker pool for Agent Engine deployment**

**Doc file**: docs/deploy/agent-runtime/deploy.md

**Current state**:
> For `region`, you can find a list of the supported regions on the
> [Agent Builder locations page](https://docs.cloud.google.com/agent-builder/locations#supported-regions-agent-engine).

**Proposed Change**:
> For `region`, you can find a list of the supported regions on the
> [Agent Builder locations page](https://docs.cloud.google.com/agent-builder/locations#supported-regions-agent-engine).
>
> If your organization uses VPC Service Controls (VPC-SC) or requires container builds to run on a private network, you can specify a private Cloud Build worker pool by adding the `--worker_pool` flag (e.g., `--worker_pool=projects/MY_PROJECT/locations/MY_REGION/workerPools/MY_POOL`). Alternatively, you can specify `worker_pool` or `build_config.worker_pool` in your `.agent_engine_config.json` file.

**Reasoning**:
The v2.8.0 release introduces support for Cloud Build private worker pools in Agent Engine deployments via the `--worker_pool` CLI flag and config file, enabling deployment in VPC-SC and private network environments.

**Reference**: src/google/adk/cli/cli_deploy.py

### 4. **Native authentication resolution for Agent Registry**

**Doc file**: docs/integrations/agent-registry.md

**Current state**:
> ### Remote A2A Agents
>
> If you are connecting to a Google A2A agent, you need to pass an
> `httpx.AsyncClient` configured with Google authentication headers to the
> `get_remote_a2a_agent` method.
>
> Example:
> ```python
> import httpx
> import google.auth
> from google.auth.transport.requests import Request
>
> class GoogleAuth(httpx.Auth):
> def __init__(self):
> self.creds, _ = google.auth.default()
> def auth_flow(self, request):
> if not self.creds.valid:
> self.creds.refresh(Request())
> request.headers["Authorization"] = f"Bearer {self.creds.token}"
> yield request
>
> httpx_client = httpx.AsyncClient(auth=GoogleAuth(), timeout=httpx.Timeout(60.0))
> remote_agent = registry.get_remote_a2a_agent(
> f"projects/{project_id}/locations/{location}/agents/YOUR_AGENT_ID",
> httpx_client=httpx_client,
> )
> ```

**Proposed Change**:
> ### Remote A2A Agents
>
> Authentication for Google A2A agents is now automatically handled by the ADK. When you call `get_remote_a2a_agent`, the Agent Registry client automatically resolves the appropriate authentication provider scheme from the agent's IAM bindings, meaning you do not need to manually configure and pass an authenticated `httpx.AsyncClient`.
>
> Example:
> ```python
> # Authentication is resolved automatically from the registry bindings.
> remote_agent = registry.get_remote_a2a_agent(
> f"projects/{project_id}/locations/{location}/agents/YOUR_AGENT_ID"
> )
> ```
>
> If you need to override the automatically resolved authentication, you can pass custom `auth_scheme` and `auth_credential` parameters directly to `get_remote_a2a_agent`.

**Reasoning**:
Agent Registry's `get_remote_a2a_agent` was updated in v2.8.0 to automatically resolve the `auth_scheme` from the agent's IAM bindings via `GcpAuthProviderScheme`, leveraging the new native authentication capabilities of `RemoteA2aAgent` and eliminating the need to manually pass an authenticated `httpx.AsyncClient`.

**Reference**: src/google/adk/integrations/agent_registry/agent_registry.py

### 5. **New Model Armor Integration**

**Doc file**: docs/integrations/model-armor.md

**Current state**:
> (New file)

**Proposed Change**:
> Create a new documentation page for the Model Armor integration. It should document the `ModelArmorPlugin` and `ModelArmorConfig`. Detail that it screens user inputs (via `prompt_template_name`) and model outputs (via `response_template_name`) using Google Cloud Model Armor. Mention that it works in both unary (`run_async`) and live (`run_live`) modes using standard callbacks, and describe how to configure blocked messages (`input_blocked_message`, `output_blocked_message`) and failure behavior (`block_on_screening_failure`). Note the requirement to install `google-adk[gcp]` to use it.

**Reasoning**:
The v2.8.0 release introduces a brand new native integration plugin for Google Cloud Model Armor, adding powerful input/output safety guardrails, which currently lacks a dedicated documentation page.

**Reference**: src/google/adk/integrations/model_armor/_plugin.py

### 6. **Context Caching for Anthropic Claude models**

**Doc file**: docs/context/caching.md

**Current state**:
> # Context caching with Gemini
>
>

>
> When working with agents to complete tasks, you may want to reuse extended
> instructions or large sets of data across multiple agent requests to a
> generative AI model. Resending this data for each agent request is slow,
> inefficient, and can be expensive. Using context caching features in generative
> AI models can significantly speed up responses and lower the number of tokens
> sent to the model for each request.
>
> The ADK Context Caching feature allows you to cache request data with generative
> AI models that support it, including Gemini 2.0 and higher models. This document
> explains how to configure and use this feature.

**Proposed Change**:
> # Context caching
>
>

>
> When working with agents to complete tasks, you may want to reuse extended
> instructions or large sets of data across multiple agent requests to a
> generative AI model. Resending this data for each agent request is slow,
> inefficient, and can be expensive. Using context caching features in generative
> AI models can significantly speed up responses and lower the number of tokens
> sent to the model for each request.
>
> The ADK Context Caching feature allows you to cache request data with generative
> AI models that support it, including Gemini 2.0 and higher models, as well as Anthropic Claude models (via Vertex AI or LiteLLM). For Claude models, caching utilizes Anthropic's ephemeral prompt caching mechanism through `cache_control` blocks. This document
> explains how to configure and use this feature.

**Reasoning**:
The v2.8.0 release introduces support for context caching (`ContextCacheConfig`) for Anthropic Claude models, so the documentation should be updated to reflect that it is no longer exclusive to Gemini.

**Reference**: src/google/adk/models/anthropic_llm.py

### 7. **Explicit memory_id support in Memory Bank**

**Doc file**: docs/sessions/memory.md

**Current state**:
> - **Direct Creation (Default):** By default, `add_memory` calls the underlying
> `memories.create` API. Each `MemoryEntry` you provide is added as a distinct,
> separate memory item.

**Proposed Change**:
> - **Direct Creation (Default):** By default, `add_memory` calls the underlying
> `memories.create` API. Each `MemoryEntry` you provide is added as a distinct,
> separate memory item. If you set the `id` field on a `MemoryEntry` (or provide `"memory_id"` in `custom_metadata`), it will be used as the final component of the memory resource name instead of letting the service generate one.

**Reasoning**:
The v2.8.0 release introduces the ability to specify an explicit `memory_id` when calling `add_memory` to create Memory Bank entries with predictable resource names.

**Reference**: src/google/adk/memory/vertex_ai_memory_bank_service.py

### 8. **Configurable API Version for Gemini/Vertex**

**Doc file**: docs/agents/models/google-gemini.md

**Current state**:
> ## Gemini Interactions API {#interactions-api}

**Proposed Change**:
> ## Configure API Version
>
> For the Vertex AI backend, the google-genai SDK defaults to `v1beta1`, which exposes the latest preview features. Production deployments that require a stable, SLA-eligible endpoint can override this default to use the GA Vertex AI API (`v1`).
>
> You can set the API version explicitly on the `Gemini` model configuration using the `api_version` parameter:
>
> ```python
> from google.adk.models import Gemini
>
> model = Gemini(model="gemini-2.5-pro", api_version="v1")
> ```
>
> Alternatively, you can configure it globally by setting the `GOOGLE_GENAI_API_VERSION` environment variable (e.g., `export GOOGLE_GENAI_API_VERSION="v1"`). An API version embedded directly in the `base_url` path (e.g., a trailing `/v1`) takes precedence over both.
>
> ## Gemini Interactions API {#interactions-api}

**Reasoning**:
The v2.8.0 release introduces explicit control over the Google GenAI SDK's API version via the `api_version` property on the `Gemini` class and the `GOOGLE_GENAI_API_VERSION` environment variable, enabling users to easily switch between `v1` and `v1beta1`.

**Reference**: src/google/adk/models/google_llm.py

### 9. **interaction_status flag for LlmResponse**

**Doc file**: docs/live/dev-guide/part3.md

**Current state**:
> | **[Text Events](#text-events)** | Model's text responses when using `response_modalities=["TEXT"]`; includes `partial`, `turn_complete`, and `interrupted` flags for streaming UI management |

**Proposed Change**:
> | **[Text Events](#text-events)** | Model's text responses when using `response_modalities=["TEXT"]`; includes `partial`, `turn_complete`, `interaction_status`, and `interrupted` flags for streaming UI management. `interaction_status` is an Enum value (`IN_PROGRESS` or `IDLE`) indicating if the model is fully done responding to the user's prompt or will take multiple turns. |

**Reasoning**:
The v2.8.0 release introduces `interaction_status` to `LlmResponse` (and consequently `Event`), allowing developers to disambiguate whether `turn_complete` means the model is finished (`IDLE`) or will follow up with another turn (`IN_PROGRESS`).

**Reference**: src/google/adk/models/llm_response.py

### 10. **Data Agent lifecycle management tools**

**Doc file**: docs/integrations/data-agent.md

**Current state**:
> * **`list_accessible_data_agents`**: Lists Data Agents you have permission to access in the configured GCP project.
> * **`get_data_agent_info`**: Retrieves details about a specific Data Agent given its full resource name.
> * **`ask_data_agent`**: Chats with a specific Data Agent using natural language.

**Proposed Change**:
> * **`list_accessible_data_agents`**: Lists Data Agents you have permission to access in the configured GCP project.
> * **`get_data_agent_info`**: Retrieves details about a specific Data Agent given its full resource name.
> * **`ask_data_agent`**: Chats with a specific Data Agent using natural language.
> * **`create_data_agent`**: Creates a new Data Agent.
> * **`update_data_agent`**: Updates an existing Data Agent.
> * **`delete_data_agent`**: Deletes a Data Agent.
>
> Note: The modification tools (`create_data_agent`, `update_data_agent`, and `delete_data_agent`) are only available if `enable_data_agent_modification` is set to `True` in your `DataAgentToolConfig`.

**Reasoning**:
The v2.8.0 release introduces new Data Agent lifecycle management tools (`create_data_agent`, `update_data_agent`, `delete_data_agent`) which are gated by the `enable_data_agent_modification` configuration flag.

**Reference**: src/google/adk/tools/data_agent/data_agent_toolset.py

### 11. **MCP tools list caching**

**Doc file**: docs/tools-custom/mcp-tools.md

**Current state**:
> 5. **Filtering (Optional):** You can use the `tool_filter` parameter when creating an `McpToolset` to select a specific subset of tools from the MCP server, rather than exposing all of them to your agent.

**Proposed Change**:
> 5. **Filtering (Optional):** You can use the `tool_filter` parameter when creating an `McpToolset` to select a specific subset of tools from the MCP server, rather than exposing all of them to your agent.
> 6. **Caching (Optional):** You can set `tool_list_cache_ttl_seconds` to cache the tools list response from the MCP server for a specific duration, avoiding a network round-trip on every turn.

**Reasoning**:
The v2.8.0 release introduces `tool_list_cache_ttl_seconds` to `McpToolset` to cache the `tools/list` response, optimizing performance for remote MCP servers.

**Reference**: src/google/adk/tools/mcp_tool/mcp_toolset.py

## Bug Fixes and Security Enhancements

### 12. **Sub-agent limitation for EnterpriseWebSearchTool**

**Doc file**: docs/tools/limitations.md

**Current state**:
> !!! warning
>
> Built-in tools cannot be used within a sub-agent, with the exception of
> `GoogleSearchTool` and `VertexAiSearchTool` in ADK Python because of the
> workaround mentioned above.

**Proposed Change**:
> !!! warning
>
> Built-in tools cannot be used alongside sub-agents (agent delegation), with the exception of
> `GoogleSearchTool` and `VertexAiSearchTool` in ADK Python because of the
> workaround mentioned above. Note that `EnterpriseWebSearchTool` does not support this workaround and cannot be combined with sub-agent delegation.

**Reasoning**:
ADK LLM Flow refactoring explicitly prevents `EnterpriseWebSearchTool` from being combined with sub-agent delegation since the Gemini API does not allow it and it doesn't support the `bypass_multi_tools_limit` workaround.

**Reference**: src/google/adk/flows/llm_flows/agent_transfer.py

### 13. **Security redaction and restricted permissions for DebugLoggingPlugin**

**Doc file**: docs/observability/logging.md

**Current state**:
> #### Full debug capture to a file
>
>

>
> To record the same activity in full, as YAML appended to `adk_debug.yaml` rather than truncated console output, use the `DebugLoggingPlugin`:

**Proposed Change**:
> #### Full debug capture to a file
>
>

>
> To record the same activity in full, as YAML appended to `adk_debug.yaml` rather than truncated console output, use the `DebugLoggingPlugin`.
>
> In Python, the `DebugLoggingPlugin` automatically redacts credential objects (such as `AuthCredential`), any state keys containing sensitive substrings (like `api_key` or `password`), and armored private keys. However, the output file still holds raw prompts and responses, so it is created with restricted `0o600` file permissions.

**Reasoning**:
The v2.8.0 release significantly enhances `DebugLoggingPlugin` security by automatically redacting sensitive credentials and enforcing `0o600` file permissions to prevent accidental exposure.

**Reference**: src/google/adk/plugins/debug_logging_plugin.py

### 14. **Safe unpickling restriction for session migrations**

**Doc file**: docs/sessions/session/migrate.md

**Current state**:
> A migration script is provided to facilitate the migration process. The script
> reads data from your existing database, converts it to the new format, and
> writes it to a new database. You can run the migration using the ADK Command
> Line Interface (CLI) `migrate session` command, as shown in the following examples:

**Proposed Change**:
> A migration script is provided to facilitate the migration process. The script
> reads data from your existing database, converts it to the new format, and
> writes it to a new database. You can run the migration using the ADK Command
> Line Interface (CLI) `migrate session` command, as shown in the following examples:
>
> If your v0 database contains arbitrary Python objects (e.g., callables or custom classes) in its state, the migration will fail for security reasons because ADK now restricts unpickling to known types. To migrate a database you trust that contains such objects, add the `--allow-unsafe-unpickling` flag to your command.

**Reasoning**:
The v2.8.0 release introduces a restricted unpickler for legacy session state to prevent arbitrary code execution vulnerabilities. Session migration will now fail on databases containing arbitrary objects unless the user explicitly passes the new `--allow-unsafe-unpickling` flag to authorize reading them.

**Reference**: src/google/adk/sessions/migration/migrate_from_sqlalchemy_pickle.py

Start with the v2.7.1...v2.8.0 comparison and the referenced source files, then review the named pages including docs/runtime/runconfig.md, docs/a2a/quickstart-consuming.md, docs/deploy/agent-runtime/deploy.md, and docs/integrations/agent-registry.md. Update each listed page and add docs/integrations/model-armor.md so the documented release features, configuration examples, and integration behavior match v2.8.0.

Written by the indexing model from the issue text.