Design: how should the reserved 'pushNotifications' transport work? (propose aligning with A2A PushNotificationConfig)

## Question / design discussion

`TransportCapabilities.pushNotifications` is reserved in the spec — *"Set `true` if the agent can send async updates via webhooks after a run finishes."* — but there's no mechanism defined: no config type, no way for a client to register a webhook, no payload/auth contract, and no integration implements it. I'd like to nail down the intended design, and I think **A2A already solved exactly this**, so AG-UI could align with it rather than invent a parallel scheme.

### What `pushNotifications` is

SSE / WebSocket / httpBinary are all **connection-based** — the client stays connected and receives events live. `pushNotifications` is the opposite: the client registers a **webhook URL**, disconnects, and the server **POSTs an out-of-band update** when the run finishes (or a background task progresses). It's the disconnection-resilient, fire-and-forget counterpart for long-running / deferred work and non-persistent clients (mobile, server-to-server).

(Complementary to the separately-reserved `resumable`: `resumable` = reconnect an open stream and replay missed events; `pushNotifications` = no stream at all, get called back.)

### Why align with A2A

A2A already has a battle-tested push-notification design, and ADK's A2A server (`to_a2a`) already ships the infra for it (`push_config_store` / `PushNotificationConfigStore`). Reusing that shape means an ADK agent exposed over both A2A and AG-UI shares one mechanism.

A2A's model (stable in the spec):

- **`PushNotificationConfig`**: `{ url, token?, authentication?: { schemes: string[], credentials? }, id? }` — the client-supplied webhook endpoint + how the server authenticates to it.
- Lifecycle RPCs: set / get / list / delete the config per task (`TaskPushNotificationConfig`, `Get/List/DeleteTaskPushNotificationConfigRequest`), and a `PushNotificationNotSupportedError` when unsupported.
- The server POSTs task status/artifact updates to `url`, authenticating with the configured `token`/`authentication`.

### Proposed shape for AG-UI (for discussion)

1. **Config type** mirroring A2A: `PushNotificationConfig { url, token?, authentication?: { schemes, credentials? }, id? }`.
2. **Registration**: a field on `RunAgentInput` (e.g. `pushNotificationConfig`) so it's set at run start — simplest for the AG-UI "one POST starts a run" model — and/or A2A-style set/get/delete endpoints for managing it out of band.
3. **Payload**: what gets POSTed to the webhook? Options — (a) the terminal events (`RUN_FINISHED` / `RUN_ERROR`, with `outcome`), (b) a compact "run `{runId}` finished" ping that the client then reconciles via the existing `POST /agents/state`, or (c) the full buffered event list. I'd lean toward (a)+(b): a small signed notification, with `/agents/state` as the source of truth.
4. **Auth & delivery**: bearer `token` / `authentication` like A2A, plus signature verification, retries with backoff, and at-least-once semantics (client dedupes on `runId`).
5. **When it fires**: only after the run finishes (per the capability's wording), or also for background-task progress? A2A fires on task updates; AG-UI could start with "on run finish" and extend later.
6. **Negotiation**: server advertises `transport.pushNotifications: true`; client opts in by supplying the config.

### Ask

Could a maintainer confirm the intended direction for `pushNotifications` — in particular whether **aligning the config/auth shape with A2A's `PushNotificationConfig`** is desirable, and **how the client should register the webhook** (a `RunAgentInput` field vs A2A-style config-management endpoints)? Once the contract is settled I'm happy to implement the `ag-ui-adk` side, especially since the ADK A2A server already has push-config infrastructure to build on. Flagging it as design-first because it adds a new config type to core, not just an ADK-middleware change.