[Epic] Idempotency & safe retries

## Idempotency & safe retries

### Problem

If a client crashes (or the connection drops) after sending the first message but before it receives and persists the server-generated `taskId`/`contextId`, it has no way to learn whether a task was started on its behalf — and no safe way to retry. There is no transport-level mechanism to deduplicate retried requests.

### Consolidated issues

- [ ] #928 — Idempotency hole when sending the first message *(anchor; `v1.1-candidate`, defines the problem)*
- [ ] #1893 — Standardize an `Idempotency-Key` header for the JSON-RPC/HTTP binding *(proposed mechanism)*

### Acceptance criteria

- The spec defines an idempotency mechanism for message send (client-supplied idempotency key and/or a defined retry/replay contract).
- Server-side deduplication semantics are specified (what a server MUST do on a repeated key).
- Mechanism is expressed consistently across all three bindings.
- Security considerations are addressed (idempotency keys MUST NOT enable unauthorized cross-client interaction with a task — the original reason compound/client-set IDs were removed).

### Notes

#928 is the problem statement; #1893 is one concrete solution (an `Idempotency-Key` header). Resolve them together so the chosen mechanism actually closes the #928 hole.