feat: add Rust A2A 1.0 runtime support

[crivetimihai]

Summary

• add an experimental Rust A2A sidecar and gateway delegation path for registered A2A agents
• normalize A2A v1 and legacy JSON-RPC payloads through a shared outbound protocol adapter
• move the example and compose testing path to A2A 1.0.0 by default while retaining legacy interop

Details

• add tools_rust/a2a_runtime with health and invoke endpoints, plus container and entrypoint wiring for RUST_A2A_MODE=off|shadow|edge|full
• route A2A service and A2A tool invocations through shared request preparation and optional Rust-side delegation
• rewrite the Go echo agent to serve a v1 card and task surface without the old Go SDK dependency, while still accepting legacy aliases
• replace the integration fixture with direct v1 coverage and update load and compose flows to exercise the v1 default path through the managed Rust sidecar

---

Refs #1624

[lucarlig]

was working on same PR last month check if anything is useful and worth stealing from it #3250 so we can close it

[dima-zakharov]

The implementation of the protocol adapter and the managed lifecycle looks very solid.

That said, the idea of Python serving requests and processing them with Rust feels less efficient than the opposite approach. We should look at the Nginx Unit: a native listener handles the socket and routes traffic to Python as a service.

In that configuration, you can easily specify how many Python workers to start for the endpoints. The Nginx Unit architecture usually provides the fastest RPS—outperforming multi-worker setups like Uvicorn, Gunicorn, or Granian.
The current sidecar MCP runtime design follows similar approach like Nginx UNit, but we can't really run multiple Python workers effectively on UDS unless we use HTTP with something like Unit or other asgi servers anyway.

[lucarlig]

This is a strong piece of work overall. The Rust A2A runtime direction, protocol normalization work, and sidecar boundary are all promising. I do think there are a few high-priority issues worth addressing before merge:

1. The Rust A2A entrypoint appears to authorize every JSON-RPC method as invoke before branching into task reads, card lookups, and push-config operations. That means the new per-method A2A authz endpoints do not seem to be exercised, so RBAC behavior for read-oriented methods looks weaker than intended.

2. The new trusted agent-resolve path appears to bypass agent visibility scoping. The existing Python invoke flow checks access before returning an agent, but the internal Rust resolve path looks like it can return any enabled agent by name without consulting forwarded auth context or token teams. That seems likely to expose private or team-scoped agents through the sidecar path.

3. The task proxy path looks like it forwards the wrong parameter shape. The Rust side passes raw JSON-RPC params through to the internal Python task endpoints, but those endpoints expect gateway-style task identifiers, while the protocol normalization and integration coverage in this PR use spec-shaped task params. As written, valid task requests may fail on the Rust path.

4. The new queue implementation does not appear to deliver the concurrency it advertises. The batching path acquires a semaphore permit but still awaits each invoke inline before moving to the next request group, so work stays effectively serial per worker thread. That looks like a throughput regression in the new hot path.

5. The default queue mode appears to be unbounded. With no explicit queue limit configured, submissions can continue accumulating even after the bridge channel is saturated, which makes overload scenarios look vulnerable to unbounded memory growth.