[Bug]: JSON-RPC client accepts responses with missing or invalid jsonrpc version

## What happened

The JavaScript client accepts an HTTP 200 JSON-RPC response even when its `jsonrpc` member is missing or is not `"2.0"`. The same behavior occurs for JSON-RPC envelopes delivered as SSE events.

For example, this successful response is currently decoded as a normal A2A result:

```json
{
"result": {
"message": {
"messageId": "m-1",
"role": "ROLE_AGENT",
"parts": []
}
},
"id": 1
}
```

A response with `"jsonrpc": "1.0"` is also accepted.

## What I expected

The client should reject malformed JSON-RPC response envelopes unless `jsonrpc` is exactly `"2.0"`. The validation should apply to both unary responses and each streaming SSE event.

## Steps to reproduce

1. Create a `JsonRpcTransport` with a custom `fetch` implementation.
2. Have the fetch implementation return HTTP 200 and the JSON response above (or change the version to `"1.0"`).
3. Call `sendMessage` with an otherwise valid `SendMessageRequest`.
4. Observe that the promise resolves with the decoded message instead of reporting a malformed JSON-RPC response.
5. Repeat with a `text/event-stream` response whose event data uses the same malformed envelope.

## Additional context

A2A section 6.11.2 requires the JSON-RPC Response `jsonrpc` member to be exactly `"2.0"`; the response must also contain either `result` or `error`. Strict envelope validation would improve cross-SDK interoperability and make malformed upstream or proxy responses visible to callers.

Suggested scope: add shared response-envelope validation for unary and streaming paths, with regression tests for missing and non-`2.0` versions.