refactor(samples): per-request processors in the Gemini Enterprise samples

[nan-yu]

Stacked on #3271. The unkeyed v0.8 capabilities need #3265, which has merged.

The v0.8 Agent Engine and Cloud Run samples and the v0.9 sample now follow the per-request model from #3269 and #3270, as the core samples do.

1. Each request gets its own A2uiRequestProcessor, negotiated from the capabilities the client sent, passed through unchanged. Gemini Enterprise doesn't name the catalogs it renders, so a request without capabilities gets GEMINI_ENTERPRISE_CAPABILITIES. In the v0.8 samples these use the unkeyed shape the v0.8 specification defines.
2. The system prompt is built from that processor, and responses are read with open_stream or parse_response and turned into A2A parts with stream_response_to_parts and to_a2a_parts. On a validation error the agent asks the model to try again. It doesn't retry an empty response, or a streamed response that already sent parts, and sends an error message instead. In v0_9/agent.py the final item holds the whole response, also when streaming, because Gemini Enterprise renders only the final message's parts, and the executor sends that item's parts.
3. The v0.9 sample builds a Material catalog and the Gemini Enterprise composite catalog in catalogs.py, instead of using the basic catalog. Its examples use the Material catalog. The README explains how the agent uses the SDK.
4. The Agent Engine executor activates the A2UI extension when the client requests it and otherwise answers with v0.8, as the v0.9 executor does, instead of a hardcoded version.
5. The pins move to a2ui-agent-sdk>0.9.0 and a2ui-a2a>0.1.0, since 0.9.0 and 0.1.0 have no open_stream or to_a2a_parts. a2ui-core is listed directly, since the samples import it. The unused jsonschema dependency is dropped.

Deployment

These SDK releases aren't on PyPI yet (a2ui-a2a has no release there at all), so the samples run on the SDKs in this repository through [tool.uv.sources] path entries, and the v0.9 uv.lock records them as editable paths. A deployment can't reach those paths, so:

1. build_sdk_wheels.sh builds wheels of a2ui-core, a2ui-agent-sdk and a2ui-a2a. With --use-wheels it points a project's sources at them and relocks it.
2. Both deploy.sh scripts (v0.9, v0.8 Cloud Run) deploy a temporary copy of the sample that holds the wheels, with its sources pointed at them and a fresh uv.lock.
3. The Agent Engine deploy.py builds the wheels into wheels/ and lists them in both requirements and extra_packages. It also requires a2a-sdk[http-server], since the A2A agent template's set_up() needs sse-starlette.

Once the SDKs are released, the path sources and the wheel step can go.

Testing

1. uv sync --all-packages, and import agent, agent_executor in each sample. uv run pytest samples/agent/adk/tests passes. ruff (0.15.20) and pyink are clean on the changed Python files.
2. A fake ADK runner (no LLM) replays scripted output through the v0.9 agent and the real executor: an empty response sends the error text without a retry, a streamed response that fails after a valid block isn't retried and sends no duplicate createSurface, the SSE aggregated event isn't read twice, and all 13 examples come back as valid parts, streaming and not.
3. Deploy packaging, offline: the staged Cloud Run copy of each sample, copied outside the repository, passes uv lock --check, uv sync --locked and uv export plus pip install into fresh venvs, and imports the agent with the local SDK wheels. For Agent Engine, deploy.main() runs with Vertex AI faked out. Its extra_packages are packed the way the Vertex AI SDK packs them, and its requirements install with pip into a fresh Python 3.13 venv, where the agent imports.

[gemini-code-assist]

Code Review

This pull request updates the Gemini Enterprise A2UI agent samples (v0.8 and v0.9) to integrate with the latest a2ui-agent-sdk and a2ui-a2a libraries, refactoring the agent, executor, and prompt building logic to support dynamic catalog negotiation and validation. The review feedback highlights critical issues that need to be addressed: consecutive user messages in the session history during retries can violate Gemini API role requirements and cause 400 errors; direct dictionary lookups on unsupported UI versions can trigger KeyErrors; and the retry loops do not catch general exceptions, which could crash the handlers on transient runner or API errors.