[Epic] Reliable stream resumption & event ordering

## Reliable stream resumption & event ordering

### Problem

Clients today cannot reliably recover a streaming task across a disconnect. There is no per-task event ordering, no cursor to resume from, no defined replay behavior on `tasks/resubscribe`, and ambiguous behavior when more than one stream is active for the same task. This makes long-running tasks fragile in exactly the deployments (proxied, restart-prone) A2A targets.

### Consolidated issues

- [ ] #1794 — Add a generation/version (sequence) number to `Task`/events for ordering, long-polling, and optimistic concurrency *(anchor; `v1.1-candidate`, has gitvote)*
- [ ] #1410 — No "last message ID", so a stream cannot be robustly resumed
- [ ] #1635 — Data loss during SSE reconnection: should `resubscribe` replay missed events?
- [ ] #999 — Behavior of `tasks/resubscribe` with multiple active streams per task *(adjacent: stream multiplexing)*
- [ ] #1811 — Add `TaskMessageUpdateEvent` to notify observers when messages are added to task history
- [ ] #899 — SSE reconnection / event ordering gaps

### Acceptance criteria

- Events (`TaskStatusUpdateEvent`, `TaskArtifactUpdateEvent`) carry a monotonic, per-task sequence/generation number.
- `SubscribeToTask` / `resubscribe` accepts a last-seen cursor and has **defined** replay-or-gap semantics (replay missed events, or an explicit, detectable gap signal).
- Behavior with multiple concurrent subscriptions to one task is specified.
- Changes are reflected in `a2a.proto` and all three bindings (gRPC, REST, JSON-RPC) with binding equivalence preserved.
- Conformance/TCK cases cover reconnect + missed-event detection.