refactor(samples): per-request processors in the ADK toolset samples

[nan-yu]

Stacked on #3271.

rizzcharts, mcp_app_proxy and file_upload_summarizer send A2UI through SendA2uiToClientToolset. They built their processor, prompt and catalogs once, at startup, from a default renderer. They now negotiate per request, and speak A2UI v1.0 as well.

1. The executor creates an A2uiRequestProcessor for each request from the capabilities the client sent, unchanged, and writes what the request needs into the session state: the processor's format rules and the negotiated catalogs under system:a2ui_catalogs, plus the preferred catalog and its examples in rizzcharts (agent_executor.py). The state follows from the negotiated version and the client's capabilities alone, so the executor records a digest of them (system:a2ui_negotiation) and adds a session event only when they change, instead of on every request.
2. The instruction is built from the session state on each request, and the toolset and the A2UI event converter read the catalogs from the same keys, so the prompt, the tool's schema and its validation follow the request's catalogs. A client that sends no capabilities, or names none of the agent's catalogs, gets text answers, and so does a v1.0 client that lacks a catalog the agent's surfaces need (see point 7).
3. Each README explains how the agent negotiates A2UI. The rizzcharts README's cd path points at the sample's current location, and the READMEs ask for Python 3.10, as the pyproject.toml files do.
4. The rizzcharts v0.9 examples name the catalog id that the v0.9 rizzcharts catalog declares; the old GitHub URL they named isn't the id of any active catalog. The agent loads and validates each catalog's examples once, at startup, against the catalogs their surfaces use (agent.py), and gives a request the examples of the client's most preferred catalog whose examples use only catalogs the client named.
5. The samples pin a2ui-agent-sdk>=0.9.0, as does the orchestrator sample, and the unused jsonschema dependency is dropped (with the matching uv.lock entries). The three executors take override from typing_extensions, since typing.override needs Python 3.12, so the samples depend on typing-extensions>=4.4.0.

v1.0 support

6. rizzcharts adds a v1.0 generator next to v0.8 and v0.9, and mcp_app_proxy and file_upload_summarizer next to v0.9. mcp_app_proxy no longer speaks v0.8: its tools write v0.9 messages for anything but v1.0, so a v0.8 client got messages it can't read, and the unused v0.8 catalog is removed. For v1.0 the executors read the renderer capabilities from a2uiRendererCapabilities, as the v1.0 A2A extension defines; v0.8 and v0.9 keep a2uiClientCapabilities. The key is A2UI_RENDERER_CAPABILITIES_KEY in a2ui.constants, next to A2UI_CLIENT_CAPABILITIES_KEY; docs(python/agent): document per-request processors, RendererState and streaming #3271 adds it.
7. On v1.0 the samples mix catalogs on one surface, so each v1.0 custom catalog holds only its custom components, has its own v1.0 catalog id, and says so in its instructions: Canvas, Chart and GoogleMap in rizzcharts_catalog_definition.json, FileUpload in file_upload_catalog.json, and the MCP App components in mcp_app_catalog.json, which drops the v0.9 Column that no surface uses. A v1.0 surface takes the basic catalog as its default (createSurface.catalogId), and each custom component names its catalog in its own catalogId; the basic catalog also resolves file_upload's required check. A v1.0 client names both catalogs in supportedCatalogIds, and the rizzcharts executor then passes both to the prompt and the toolset's validation; a basic-only client gets the basic catalog and the standard examples, and a client that names only the rizzcharts catalog gets text answers, since a v1.0 rizzcharts surface defaults to the basic catalog. file_upload_summarizer's v1.0 generator registers the basic catalog next to its own, and a v1.0 client that names only one of the two gets text answers. mcp_app_proxy's surfaces use only MCP App components, so they keep that catalog as their default. v0.8 and v0.9 are unchanged: a surface there uses one catalog, so their custom catalogs keep the copied basic components.
8. The four rizzcharts examples have v1.0 copies under rizzcharts_catalog/1.0 and standard_catalog/1.0, with {"@path": ...} bindings and no theme. The rizzcharts*catalog ones use the basic catalog as the surface default, and their Canvas, Chart and GoogleMap name the rizzcharts catalog; the standard_catalog ones use the basic catalog alone. As with the basic catalog's v1.0 Text, headings are Markdown, and component ids use *instead of-.
9. The rizzcharts examples of every version set the data model to flat keys such as "chart.items[0].label" and bound /chart.items, which names no data, and the components a List template repeats bound absolute paths such as /label. They now send a nested data model, bind /chart/items and the like, and bind template items relative to the item (label, ${name}). v0.8 can't nest more than one level in a dataModelUpdate, so the v0.8 examples send one per level; the v0.8 renderer of the Angular orchestrator client resolves the new paths.
10. mcp_app_proxy and file_upload_summarizer write the request's version to the session state (system:a2ui_version), and their tools write v1.0 messages (@path, @call, the v1.0 catalog id) for a v1.0 request. The event converter sends tool responses on unvalidated, so the file upload tools validate their messages against the negotiated catalogs and return an error to the model instead of a surface the client can't render. The v0.9 file upload catalog gains the required function of the v0.9 basic catalog, which the v0.9 uploader's button check calls and the Angular file upload client already implements.
11. part_converter.py: A2uiPartConverter defaulted to v0.8, and the toolset and event converter pass no version, so v1.0 parts went out with the deprecated application/json+a2ui MIME type. The version now defaults to the protocol version of the catalogs, so v0.8 and v0.9 output is unchanged.
12. The orchestrator sample is unchanged: its subagents advertise v0.8 and v0.9 but not v1.0, and supporting v1.0 there also needs the SDK's data model stripping to read a2uiRendererDataModel.

Testing

1. uv run pytest (the whole suite), including a new part converter test and two new sample test modules: test_rizzcharts_examples.py validates each rizzcharts example against exactly the catalogs its surfaces use and checks that every binding resolves in the data model it sends, and test_community_adk_toolset_samples.py drives each executor's _prepare_session without a model: the text fallbacks of points 6 and 7, the rizzcharts example choice, the session events of point 1, and the file upload tools' payloads and errors.
2. A script that creates a processor for each version in each sample, with clients naming every catalog, the catalogs in reverse order, and each catalog alone, builds the prompt, and validates the examples and tool payloads against the negotiated catalogs.
3. A real v1.0 request to rizzcharts with gemini-3.6-flash (at 651616f, before the data model change of point 9), from a client naming both catalogs: it returned createSurface on the basic catalog, updateComponents with Canvas and Chart naming the rizzcharts catalog, and updateDataModel, as application/a2ui+json.
4. ruff check, pyink and Prettier on the changed files; uv run prompt_builder.py 0.8|0.9|1.0 for rizzcharts.

[gemini-code-assist]

Code Review

This pull request refactors A2UI negotiation across multiple agents (file_upload_summarizer, mcp_app_proxy, and rizzcharts) to use a single runner that dynamically adapts its instructions based on session state, while upgrading the a2ui-agent-sdk dependency and removing jsonschema. The review feedback correctly identifies a copy-paste bug in the rizzcharts agent's name initialization, a type mismatch in the examples path dictionary annotation, and an unnecessary performance bottleneck caused by validating static examples on every request.