[BUG] Custom MCP SSE message endpoints create a different transport and cannot resolve the SSE session #8045

Environment

Current master 34f2ed036747936a5e28aea2c94cd9b3cddcce47; MCP server plugin, SSE transport.

Reproduction

1. Configure selector /mcp/** with handle {"messageEndpoint":"/rpc"} and an enabled tool rule.
2. Open an SSE connection at /mcp. The server advertises /mcp/rpc?sessionId=<id>.
3. POST an MCP JSON-RPC initialization message to the advertised URL using that session ID.

Code-derived actual behavior

The original SSE connection belongs to the transport keyed by /mcp. However, handleSseRequest passes the full incoming /mcp/rpc URI to getOrCreateMcpServerTransport. normalizeServerPath strips only fixed suffixes (/message, /sse, /streamablehttp), so /mcp/rpc becomes a different server key. A new transport is created, and its session map does not contain the original SSE session. The message handler returns 404 Session not found. It also leaves an unintended extra server/transport registered.

Code evidence

• SSE and message request dispatch: looks up transport by request URI even though the cached selector server already has its canonical path.
• Transport lookup/creation: transport ownership is based on the normalized incoming URI.
• Server-path normalization: custom message suffixes are not resolved to their owning selector server.
• Session lookup: sessions are local to each transport; an unknown ID produces 404.

Expected behavior / acceptance

Use the matched selector's canonical server path to obtain its SSE transport; resolve the configured message endpoint separately from server identity. Add coverage with a non-default endpoint such as /rpc: SSE setup and subsequent JSON-RPC POST must share the same transport/session, with no extra shared server created. Keep /message compatibility coverage.

Validation

Confirmed through source-level tracing, not an executed end-to-end reproduction. This occurs on initial configuration and does not require an endpoint update.