.NET: [Feature]: First-party A2UI agent integration for .NET (like Python agent_framework_ag_ui._a2ui)

### Description

### What problem does it solve?

The Python agent-framework package ships a complete A2UI integration under `agent_framework_ag_ui._a2ui` (`A2UIAgent`, `enable_a2ui`, `generate_a2ui` / `render_a2ui` tooling, catalog forwarding, progressive paint, validate→retry recovery). .NET (Microsoft Agent Framework dotnet) has no equivalent first-party package today.

As a result, .NET developers who want A2UI surfaces in their agents have to reverse-engineer the Python reference (`_a2ui/_agent.py`, `ag_ui_a2ui_toolkit`) and maintain a community port. It is unclear whether the .NET team plans parity, or whether we should build/maintain this ourselves.

### What would the expected behavior be?

Provide an official `Microsoft.Agents.AI.AGUI.A2UI` (or similar) package for .NET that mirrors the Python `_a2ui` design:

- `A2UIAgent` wrapper / `enable_a2ui(...)` helper
- Planner-facing `generate_a2ui` tool + render sub-agent forced to call `render_a2ui`
- Progressive paint: stream `render_a2ui` argument fragments to the client via AG-UI
- Validate→retry recovery loop
- Component catalog forwarding from `RunAgentInput.context` (`a2ui_schema`)
- Multi-turn tool-call sanitation (unanswered `render_a2ui` / `generate_a2ui` calls)

If a first-party package is not planned, official guidance on how the .NET community should self-integrate with `ag-ui-a2ui-toolkit` semantics would be equally valuable.

### Design questions

While building our own .NET prototype, we hit a few architectural questions that affect whether we align with the Python implementation:

1. Is the planner + render-sub-agent split required primarily to enable *progressive paint* (streaming `render_a2ui` argument fragments incrementally), or is it mostly separation-of-concerns + recovery? Could a single-agent model-driven approach stream progressively using AG-UI `TOOL_CALL_ARGS` deltas?
2. Is `a2ui_schema` in `RunAgentInput.context` the canonical, cross-language-stable channel for catalog forwarding?
3. Is there a public roadmap for .NET A2UI support, or should the Python `_a2ui` + `ag_ui_a2ui_toolkit` be treated as the reference implementation to port?

Happy to share our prototype and help validate an official .NET design.

### Alternatives considered

Maintaining a community port of the Python `_a2ui` adapter on top of `Microsoft.Agents.AI`. This works, but risks drifting from upstream toolkit changes and from the official wire semantics.

### Code Sample

```markdown

```

### Language/SDK

.NET