fix(mcp-bridge): only queue messages for sessions with a live connection

[shreemaan-abhishek]

Description

The mcp-bridge plugin exposes a message endpoint (POST /message?sessionId=...) that enqueues the request body into the mcp-session shared dictionary, keyed by the sessionId query argument. Today that argument is taken as-is: a server is created for whatever sessionId is supplied and the body is pushed onto <sessionId>:queue, with a -- TODO: check ctx.var.arg_sessionId marking the missing validation. Because there is no check that the session has a live SSE connection, and the queue keys have no TTL or length bound, messages can be queued under session ids that no consumer will ever drain, and those queues stay in shared memory until the worker is reset.

This PR makes the message endpoint accept only sessions that currently have a live SSE connection, and bounds the per-session queue:

• When an SSE connection is established, the session registers a marker in the shared dictionary (<sessionId>:session) before its endpoint is advertised, and the ping loop refreshes it while the connection stays open. Teardown removes the marker and the queue.
• The marker carries a TTL (60s), so it expires on its own if a session goes away without running teardown (e.g. worker reload).
• The message endpoint returns 404 when sessionId is missing or has no live session, instead of creating a server and queueing for it.
• push now bounds the queue length per session and (re)arms a TTL on the queue key, so a single session cannot grow without limit and an abandoned queue does not linger.

The session lookup is exposed as mcp_server.session_exists() (delegating to the shared-dict broker) so the message endpoint can check it without standing up a server.

Which issue(s) this PR fixes:

Fixes #

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)