SSE client rejects valid `retry:` field and ignores reconnection timing (Streamable HTTP)

Bug description

The client SSE line parser in ResponseSubscribers rejects the standard SSE retry: field, throwing:

io.modelcontextprotocol.spec.McpTransportException: Invalid SSE response. Status code: 200 Line: retry: 500

Per the SSE specification, retry: sets the stream's reconnection time, and unknown fields MUST be ignored (never error the stream). Because of this, the Streamable HTTP client:

1. can error a live SSE stream when the server sends a retry: line, and
2. does not honor the server-provided reconnection delay, reconnecting immediately.

This is the MUST-level client-sse-retry-timing failure already noted as a known limitation in conformance-tests/VALIDATION_RESULTS.md.

Environment

• java-sdk main (2.0.1-SNAPSHOT)
• Java 17+
• Transport: HttpClientStreamableHttpTransport (client), SSE / Streamable HTTP

Steps to reproduce
Run the official MCP conformance sse-retry client scenario:

./mvnw clean package -DskipTests -pl conformance-tests/client-jdk-http-client -am
npx -y @modelcontextprotocol/conformance client \
  --command "java -jar conformance-tests/client-jdk-http-client/target/client-jdk-http-client-2.0.1-SNAPSHOT.jar" \
  --scenario sse-retry

Observed:

Error: Invalid SSE response. Status code: 200 Line: retry: 500
[client-sse-retry-timing ] FAILURE  Client MUST respect the retry field (reconnected ~0ms instead of 500ms)
[client-sse-last-event-id] WARNING  Client SHOULD send Last-Event-ID on reconnection
OVERALL: FAILED

Expected behavior

• The SSE parser parses/ignores retry: (and any unknown SSE field) without erroring the stream.
• On reconnection after a drop, the client waits the server-specified retry interval before reconnecting.

Minimal reproducible example
Feeding the SSE lines id: e1 / retry: 500 / data: hello / (blank) to the SSE line subscriber currently throws McpTransportException instead of yielding a single event.

Proposed scope (two parts)

1. Parser robustness (small, self-contained): parse retry: and ignore unknown fields in ResponseSubscribers. (Implemented locally with unit tests.)
2. Reconnect timing: honor the parsed retry value before reconnecting in HttpClientStreamableHttpTransport / DefaultMcpTransportStream. This touches the McpTransportStream SPI, so I'd like to confirm the preferred approach before opening a PR.

The related Last-Event-ID SHOULD warning appears covered by #830, so I would keep it out of scope here.

Happy to open a PR for part 1 immediately and follow up on part 2 per maintainer guidance.

Start with the SSE line subscriber in ResponseSubscribers and its unit tests, reproducing the minimal retry: 500 case. Then trace reconnection handling through HttpClientStreamableHttpTransport and DefaultMcpTransportStream, including the McpTransportStream SPI. Run the sse-retry conformance scenario; done means retry fields no longer fail parsing and reconnection observes the server-provided delay.