Please do a quick search on GitHub issues first, the feature you are about to request might have already been requested.

Expected Behavior
WebMvcSseServerTransportProvider should support separate configuration for registration paths and published paths. This would allow proper operation in environments with context paths or global URL prefixes. Example usage:
// Registration path: /message (for server routing)
// Published path: /api/v1/message (what clients see/use)
var transportProvider = new WebMvcSseServerTransportProvider(
objectMapper,
"/message", // Server registration path
"/api/v1/message", // Path sent to clients
"/sse"
);
With this enhancement, the server would register handlers at the bare paths, but communicate the full paths to clients through the SSE connection.

Current Behavior

When using WebMvcSseServerTransportProvider in environments with servlet context paths or other global URL prefixes (like Spring Boot's spring.mvc.servlet.path), there's a mismatch between:

1. The path where handlers are registered with Spring's RouterFunction (e.g., /message)
2. The full path that needs to be communicated to clients (e.g., /app/message when the context path is /app)

Currently, WebMvcSseServerTransportProvider uses the same path for both registration and client communication, which doesn't work correctly in environments with context paths.
Context

I'm deploying an MCP server in a Spring Boot application with a servlet context path configured via spring.mvc.servlet.path. When registering message endpoints with Spring's RouterFunction, I need to use paths without the context prefix, but when communicating these endpoints to clients, I need to include the full path with context prefix. I've considered workarounds like:

1. Using a reverse proxy to handle path translation (adds complexity)
2. Manually modifying paths in client code (error-prone)
3. Implementing a custom transport provider (duplicates existing code)
   A simple solution would be to enhance WebMvcSseServerTransportProvider to support separate configuration for registration and published paths, which would resolve this issue cleanly.