[Epic] Bidirectional streaming & improved stream semantics

## Bidirectional streaming & improved stream semantics

The A2A protocol today only supports server-to-client streaming. A cluster of related gaps — around client-to-server streaming, first-class `Message` streaming, and semantic ambiguity between `Message` and `Artifact` — have accumulated in separate issues. This epic tracks them as a coherent unit.

## Problem areas

### 1. No client-to-server (bidirectional) streaming

The current protocol is strictly unidirectional: the server streams to the client, but the client cannot stream input to the agent. Use cases like ASR (speech recognition), real-time audio/video, and mid-task steering require a long-lived duplex channel.

- **#656** — [Feat]: Support for stream input

### 2. No first-class `Message` streaming

There is no way to stream a `Message` incrementally (token-by-token). The only streamable entity is `Artifact`, which is semantically wrong for conversational output. Implementors work around this by misusing `Artifact` or sending many small `TaskStatusUpdateEvent` messages, each of which is stored as a separate history entry.

- **#822** — [Feat]: Message object for streaming
- **#1261** — [Feat]: Make Message streaming possible
- **#1386** — [Feat]: Add token-by-token message streaming

### 3. Semantic confusion between `Message` and `Artifact`

The boundary between `Message` and `Artifact` is undefined in the spec. Both can carry user-facing content; only `Artifact` is streamable. Developers diverge on which to use for the same output, breaking interoperability and making conversation history reconstruction unreliable.

- **#1313** — [Feat]: Unify `Message` and `Artifact` to simplify streaming and semantics

### 4. Streaming specification gaps

The spec for `SendStreamingMessage` references a "final completion indicator" that has no concrete definition, and the `SubscribeToTask` return type incorrectly includes `Message` as a possible variant.

- **#1746** — [Bug]: Clarify the outputs of `SendStreamingMessage`
- **#1299** — [Bug]: return type of `SubscribeToTask` should not include the `Message` type

---

## In-flight work (context only)

The following open PRs are already proposing solutions in this space and should be considered as input to the design:

- **PR #1549** — Proposal for bidirectional streaming over gRPC (`SendLiveMessage` bidi RPC, gRPC-only)
- **PR #1975** — Bidirectional live sessions with real-time media support (extends #1549)

---

## Child issues

| # | Area | Title |
|---|------|-------|
| #656 | Bidirectional | Support for stream input |
| #822 | Message streaming | Message object for streaming |
| #1261 | Message streaming | Make Message streaming possible |
| #1313 | Semantics | Unify `Message` and `Artifact` to simplify streaming and semantics |
| #1386 | Message streaming | Add token-by-token message streaming |
| #1746 | Spec clarity | Clarify the outputs of `SendStreamingMessage` |
| #1299 | Spec clarity | `SubscribeToTask` return type should not include `Message` |