[BUG] Updating an MCP selector messageEndpoint leaves the SSE transport on the previous endpoint #8044

Environment

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

Problem and reproduction

1. Create a selector for /mcp/** with handle {"messageEndpoint":"/message"}, and a working tool rule.
2. After the server is initialized, update only its handle to {"messageEndpoint":"/sse"}, keeping the same selector ID and URI condition.
3. Open a new SSE connection at /mcp.

The selector cache now says /sse, but the existing transport still advertises /mcp/message. A client following that advertised URL no longer satisfies the plugin's uri.endsWith(messageEndpoint) check and is dispatched to SSE handling instead of message handling. The configuration becomes internally inconsistent until the server is recreated.

Code evidence

• handlerSelector compares only the server path, replaces CACHED_SERVER, and creates the SSE transport only if the server does not already exist. A handle-only update never replaces the transport.
• Transport creation returns an existing transport without comparing its endpoint configuration.
• Request dispatch uses the updated cached message endpoint.
• SSE endpoint advertisement uses the transport's immutable original endpoint.

Expected behavior / acceptance

Apply message-endpoint changes consistently to configuration, transport advertisement and request dispatch. If recreation is required, close the old transport, preserve/replay tool definitions, and define what happens to existing sessions. Add a regression covering a handle-only update and a successful JSON-RPC exchange on a newly established SSE session.

Scope and validation

Source-level call-chain review; no live gateway or end-to-end reproduction executed. Distinct from #7472: that report concerns selector URI/path migration; this trigger keeps the path unchanged.