Close WebMvcStreamableServerTransportProvider transports on disconnect

[lxq19991111]

Fixes #6860

Makes the WebMVC Streamable HTTP SSE transport close when the SSE response completes, times out, or errors, and routes SSE write failures through the transport close() path instead of only reporting the error to the SseBuilder.

It mirrors modelcontextprotocol/java-sdk#1021: listening streams close on timeout/error as well as completion, replay and streaming responses close on lifecycle events, and every lifecycle event uses the same idempotent close() (no separate markClosed() flag).

Key design point: a write failure closes only the current HTTP/SSE transport and does NOT remove the logical MCP session. Removing the session on a request-specific write failure would break the next request carrying the same mcp-session-id and Last-Event-ID replay, so session eviction is intentionally left to DELETE / keep-alive eviction.

Testing

Rewrote both tests without reflection, using a package-private transport factory seam (the provider exposes a RouterFunction, so the SDK-style servlet entry-point mocking is not applicable here):

• sseLifecycleCallbacksCloseStreamOnCompleteTimeoutAndError asserts all three lifecycle callbacks trigger the close callback.

• sseWriteFailureClosesOnlyCurrentTransportWithoutRemovingSession initializes a session over the router, triggers an SSE write failure, verifies the transport is completed, and then deletes the session with the same id, asserting 200 to prove the session was retained.

  mvn -pl mcp/transport/mcp-spring-webmvc -am \
      -Dtest=WebMvcStreamableServerTransportProviderTests \
      -Dsurefire.failIfNoSpecifiedTests=false test
  

Module unit tests pass, and WebMcpStreamableAsyncServerTransportIT, WebMcpStreamableSyncServerTransportIT, and WebMvcStreamableIT pass.

[lxq19991111]

Pushed a follow-up commit propagating SSE write failures: the transport still closes only the current connection and keeps the logical session, but sendMessage now surfaces an McpTransportException instead of completing normally, so callers stop writing to a stream that no longer leads anywhere. This matches what modelcontextprotocol/java-sdk#1130 settled on upstream. Broadcasting is unaffected: notifyClients logs and swallows per-session failures, and the keep-alive scheduler completes ping failures, so a single write failure cannot break other sessions.

Two notes on how this relates to modelcontextprotocol/java-sdk#1130 ("Streamable HTTP: Add session sweeping and close hanging streams"). It landed after the v2.0.1 tag, and it only changes HttpServletStreamableServerTransportProvider in mcp-core, not the WebMVC provider maintained here, so upgrading the MCP SDK alone does not fix DELETE-less disconnects for spring-ai-starter-mcp-server-webmvc users, and this PR is still needed. When Spring AI moves to a release containing that work, the WebMVC transport can be aligned with the new releaseTransport() and response-stream APIs separately.

The write-failure test now asserts the propagated exception and no longer verifies that the SseBuilder was completed on the mock. That assertion was a false positive: DefaultSseBuilder sets sendFailed on the first failed write, after which complete() returns immediately, so the mock verified a call that cannot happen on a real connection.