Fixes #750

McpStreamableServerTransportProvider inherits the default protocolVersions() from McpServerTransportProviderBase, which includes 2024-11-05. Streamable HTTP was introduced in 2025-03-26, so a Streamable HTTP provider advertises a version whose transport it cannot serve — the symptom reported in #750 being doGet on HttpServletStreamableServerTransportProvider being unable to initialize a session without a prior POST.

Following the direction agreed in the issue, this overrides protocolVersions() on the McpStreamableServerTransportProvider interface rather than on the servlet implementation, so every current and future Streamable HTTP provider is covered. It mirrors the existing McpStatelessServerTransport default, which already excludes 2024-11-05 for the same reason.

@Override
default List<String> protocolVersions() {
    return List.of(ProtocolVersions.MCP_2025_03_26, ProtocolVersions.MCP_2025_06_18,
            ProtocolVersions.MCP_2025_11_25);
}

HttpServletSseServerTransportProvider keeps its 2024-11-05-only override, and transports without the Streamable HTTP constraint (stdio) keep the full range.

Behavioural consequence

A client that requests 2024-11-05 against a Streamable HTTP server previously had that version echoed back, and then failed later in confusing ways. With this change McpAsyncServer takes the else branch and responds with the highest supported version (2025-11-25), logging the mismatch — which is what the spec comment in that method already prescribes. So the change turns a silent late failure into an explicit negotiation result at initialize time.

Tests

Added ServerTransportProtocolVersionsTests asserting the Streamable HTTP and stateless defaults exclude 2024-11-05 while the base default keeps the full range, so a future transport can't silently regain the unsupported version.

./mvnw test results:

• mcp-core: 358 tests, all passing (including the 3 new ones)
• mcp-test: the 109 HttpServletStreamable* tests are unaffected

For transparency, the full mcp-test module currently has 1 failure and 12 errors (ToolInputValidationIntegrationTests, HttpClientStreamableHttpTransportTest) on my machine. I verified these are pre-existing by running the whole suite on a clean checkout with this change stashed — identical counts before and after, so they are unrelated to this PR.