A2UI rendering for ADK agents on Vertex AI Agent Engine / Gemini Enterprise adkAgentDefinition registrations

## Summary

There is currently no way for an ADK agent deployed on **Vertex AI Agent Engine** and registered in **Gemini Enterprise** via `adkAgentDefinition` (`provisionedReasoningEngine`) to render A2UI in the Gemini Enterprise UI. A2UI rendering in GE appears to work only on the `a2aAgentDefinition` path (agent card advertising the A2UI extension, UI payloads travelling as A2A DataParts into `QueryPart.uiJsonPayload`).

The roadmap lists ADK integration as "🚧 In Progress — still designing developer ergonomics". This is a request to make **Agent-Engine-hosted ADK agents surfaced through Gemini Enterprise** a first-class target of that design, not just local/self-served ADK agents.

## Context — production impact

We are a Gemini Enterprise production customer. We had A2UI working end to end in the GE chat panel (interactive investigation forms, live progress checklists) with agents served over Cloud Run A2A using `a2ui-agent-sdk`'s A2A executor integration and an agent card carrying the A2UI v0.8 extension.

We then migrated those agents to the recommended canonical shape — `AdkApp` on Vertex AI Agent Engine, registered in GE as `adkAgentDefinition` — and A2UI rendering silently stopped. Tracing it, the whole chain is A2A-specific and the ADK/Agent Engine path has no equivalent for any link:

1. **Agent side**: `a2ui-agent-sdk` hooks the A2A agent executor to convert tool-emitted A2UI payloads into A2A DataParts. `AdkApp`/`streamQuery` has no executor and no converter, so the A2UI JSON rides along as opaque tool-response content.
2. **Registration side**: `adkAgentDefinition` exposes a single field (`provisionedReasoningEngine.reasoningEngine`) — there is no way to advertise the A2UI extension or any UI capability.
3. **Transport side**: GE's rendering slot (`QueryPart.uiJsonPayload`, documented as A2UI-only as of Q1 2026) is populated from A2A DataParts; there is no documented mapping from Agent Engine `streamQuery` events.

So teams currently face a choice between the recommended ADK/Agent Engine serving shape (losing A2UI in GE) or legacy self-served A2A (keeping A2UI, losing the benefits of the managed path).

## Request

Any of the following would close the gap — listed in rough order of preference:

1. A supported mechanism for A2UI on the ADK/Agent Engine path end to end: an ADK-native way to emit A2UI (e.g. the Agents SDK writing A2UI parts into the event stream) plus GE mapping `streamQuery` events into `uiJsonPayload`.
2. Native A2A serving on Agent Engine reaching a usable state, so Agent-Engine-hosted agents can register in GE as `a2aAgentDefinition` with the A2UI extension — making the existing A2A-based A2UI support apply.
3. At minimum: documentation stating clearly that A2UI in Gemini Enterprise requires the A2A registration path, so teams migrating to `adkAgentDefinition` know the trade-off before they make it.

## Questions

- Is GE-surfaced ADK/Agent Engine rendering in scope for the in-progress ADK integration on the roadmap?
- Is there a preview / trusted-tester programme covering this? We are a production consumer of the capability with daily deployments and eval harnesses exercising the full GE wire path, and can turn feedback around quickly.

## Environment

- google-adk 2.3.0 (Python), a2ui-agent-sdk 0.2.1 (A2UI v0.8 envelopes)
- Vertex AI Agent Engine (Reasoning Engine, `AdkApp`), Gemini Enterprise EU
- GE A2UI-over-A2A registration: working (April 2026 preview); `adkAgentDefinition`: no rendering

The issue describes a gap in the A2UI rendering pipeline for ADK agents on Vertex AI Agent Engine. Research the A2UI extension registration in Gemini Enterprise, the `a2ui-agent-sdk` integration for A2A, and the `AdkApp`/`streamQuery` event flow. Look for existing code that maps A2A DataParts to `uiJsonPayload` and see how `adkAgentDefinition` registrations differ. The goal is to propose a design for extending A2UI support to the ADK/Agent Engine path.

由索引模型根据 Issue 内容生成。