[nan-yu]

Stacked on #3271. Needs #3266, since these agents no longer reshape the client's capabilities.

restaurant_finder and custom-components-example kept a default processor, cached one stateful parser per session, and reshaped the client's capabilities before negotiating catalogs. They now follow the per-request model from #3269 and #3270, and speak A2UI v1.0 as well as v0.8 and v0.9.

1. Each request gets its own A2uiRequestProcessor, created by the generator for its protocol version from the capabilities the client sent, unchanged. A client that activates the A2UI extension but sends no capabilities, or none the agent can use, gets a text answer from the text runner.
2. The system prompt is built from that processor. restaurant_finder gives its examples to the generator (agent.py), so the prompt snippet lists them and creating the processor checks them against the request's catalogs.
3. Both agents read useStreaming from the request. Responses are read with processor.open_stream() when streaming and processor.parse_response() otherwise, and turned into A2A parts with stream_response_to_parts and to_a2a_parts. When streaming, the parts go out in working status updates and the final message has none; otherwise the final message holds them. On a validation error, or in restaurant_finder a response without A2UI messages, the agent asks the model to try again.
4. custom-components-example keeps a canvas RendererState per session (agent.py), since its turns update the surfaces earlier turns created. It starts a new state when processor.accepts_state(state) says the client's catalogs changed.
5. Each README gains a "How it works" section, and the unused jsonschema dependency is dropped (with the matching uv.lock entries).

Surfaces that the client already holds

From v0.9 on, creating a surface the renderer already holds is an integrity error, and both samples use fixed surface ids.

6. custom-components-example lists the surfaces in the session's state in the system prompt and in the retry message (prompt_builder.py), and tells the model to update them, or to send deleteSurface before it creates one again. Without this, a second lookup or a second "send message" in one conversation failed on both attempts. The action UIs delete their surface before they create it again, and closing the floor plan sends nothing when it isn't open.
7. restaurant_finder checks each response on its own, and remembers which surfaces each conversation's client holds. It sends deleteSurface before a response creates one of them again (a second search), and before a retry it deletes the surfaces that the failed streamed attempt created. Text that a failed streamed attempt already sent can't be taken back.

v1.0 support

8. Both agents add a v1.0 generator on the v1.0 basic catalog and advertise the v1.0 extension in their agent card. For v1.0 the executors read the renderer capabilities from a2uiRendererCapabilities (A2UI_RENDERER_CAPABILITIES_KEY in a2ui.constants, added in docs(python/agent): document per-request processors, RendererState and streaming #3271), as the v1.0 A2A extension defines; v0.8 and v0.9 keep a2uiClientCapabilities. Both accept action events sent as v0.9 or v1.0, as a single message, a list of messages, or the {"messages": [...]} wrapper; custom-components-example previously handled only v0.8 userAction. The agents still send each outbound A2UI message in its own data part, as the SDK's to_a2a_parts does.
9. Every v0.9 example has a v1.0 copy: restaurant_finder/examples/1.0 and custom-components-example/examples/1.0. They write "version": "v1.0", bind data with {"@path": ...}, and drop theme. Two differences follow from v1.0: the v1.0 basic Text has no h1 to h5 variants, so headings are Markdown (## ...), and component ids use _ instead of -, since the SDK requires v1.0 ids to be UAX Initial commit for a2ui_restaurant_finder and a generic a2UI extension. #31 identifiers.
10. custom-components-example mixes catalogs on its v1.0 surfaces. Its v1.0 inline catalog, inline_catalog_1.0.json, defines only OrgChart and WebFrame, under its own catalog id (also its $id), rather than repeating the basic catalog as the v0.9 one must. The v1.0 surfaces use the basic catalog as their default, and each OrgChart and WebFrame names the custom catalog in its catalogId. examples/1.0/floor_plan.json shows it: a basic Card, Column, Text and Button around a custom WebFrame. The floor plan UI that a2ui_examples.py builds for the view_location action does the same; the send-message UI (examples/1.0/action_confirmation.json) uses only the basic catalog.
11. Running on v1.0 exposed two bugs, fixed in both agents:
    1. ADK read {XID_Start} in the v1.0 prompt as a session state variable and failed every request with KeyError. The instruction is now passed as a function, which skips state injection, and restaurant_finder's "expression": "{expression}" workaround is gone.
    2. The token stream also yielded ADK's final aggregated event, so the parser read the whole response twice. v1.0 rejected the second createSurface, so the first attempt always failed. The aggregated event is now skipped, which also fixes doubled text in restaurant_finder's text-only answers.
12. Both READMEs explain how to run with a v1.0 client: activate .../a2ui/v1.0 in X-A2A-Extensions and send a2uiRendererCapabilities in the message metadata.

Testing

1. uv run pytest samples/agent/adk/tests, which validates the v1.0 examples too. The new test_sample_agents.py replays the examples through each agent with a fake ADK runner and mirrors the renderer's surfaces: two lookups and two send_message actions in one custom-components session, a retry after a partly streamed failure, and a restaurant_finder streaming retry and repeat search, for v0.9 and v1.0, checking that no createSurface reaches a surface the client holds. It also checks the action shapes the executors accept.
2. uv run pytest python/a2ui_agent/tests.
3. A script that creates a processor for v0.8, v0.9 and v1.0 in each sample, builds the prompt snippet, and parses every v1.0 example with parse_response (custom-components-example's later-turn example against the state its earlier turn left).
4. A real v1.0 request to each agent with gemini-3.6-flash: every returned part stated v1.0 and passed validate_payload. This was before the surface handling above, which was tested only with the fake runner.
5. pyink --check and ruff check on the changed files.

[gemini-code-assist]

Code Review

This pull request refactors the custom components and restaurant finder agent samples to utilize A2uiGenerator and A2uiRequestProcessor for negotiating client capabilities, validating streamed responses, and managing renderer states. It also removes the direct jsonschema dependency. The review feedback identifies several critical issues: missing imports for InMemoryArtifactService in both agents' code, a potential NameError in the custom components executor due to an uninitialized client_ui_capabilities variable, a memory leak risk from uncleaned self._renderer_states sessions, and a type annotation mismatch for self._generators.