Support A2A extensions

[alDuncanson]

Handler has no handling for A2A extensions: neither the A2A-Extensions request header nor AgentExtension declarations on the agent card.

Where it stands

The specification defines extensions as the mechanism agents use to advertise and negotiate non-standard capability, carried by:

• A2A-Extensions — a comma-separated list of extension URIs on the request
• AgentExtension entries in AgentCard.capabilities

A repo-wide search for extension in src/ returns nothing.

The work

• Surface card-declared extensions in card get output and the TUI card panel, so a user can at least see what an agent offers
• Allow sending A2A-Extensions — a CLI flag and per-server config, similar in shape to Support custom request headers in server config (TOML) #82's custom headers
• Decide whether Handler should warn when an agent declares an extension the client does not understand

Acceptance

• Declared extensions are visible in card output
• A requested extension URI reaches the wire

Low urgency while the extension ecosystem is small, but this is how the protocol grows, so being blind to it will not age well. Showing declared extensions is worthwhile on its own even before Handler can negotiate them.

Part of the A2A v1.0 parity work.

---

_{Context: Handler was audited against the A2A v1.0 specification after the v0.2.0 release. Method coverage at the time: service 7/11, CLI 7/11, TUI 4/11 (after #98), MCP 6/11. The four methods missing everywhere are ListTasks, ListTaskPushNotificationConfigs, DeleteTaskPushNotificationConfig, and GetExtendedAgentCard. A deterministic streaming test agent lives outside the repo at ~/code/handler-streaming-agent — it supports ask (input-required), slow (cancellable), and fail, and its card sets capabilities.streaming = true, which ADK does not do by default.}