Add proper SSE support for vMCP (beyond streamable-http session affinity)

[yrobla]

Background

The current vMCP implementation supports streamable-http transport and handles session affinity by storing pod assignment in Redis. This works well for streamable-http because any request can land on any vMCP pod and be routed correctly.

However, SSE (Server-Sent Events) has different requirements:

• SSE is a long-lived connection — the client connects once and receives a stream of events identified by event IDs.
• It is fundamentally session-oriented: the client expects to reconnect to the same backend and resume from a known event ID.
• Features like elicitation (and other push-based MCP patterns) rely on SSE even when the primary transport is streamable-http.

Problem

The current Redis-based session affinity approach solves pod restarts and horizontal scaling for streamable-http, but does not fully support SSE:

• Session affinity by client IP (at the load balancer level) does not survive pod restarts or rescheduling.
• The Redis routing layer can preserve routing after pod restarts, but SSE connections are terminated when the pod dies — there is no reconnect/resume mechanism.

What needs to be done

• Investigate the SSE reconnection/resume requirements in the MCP spec (event IDs, Last-Event-ID header).
• Determine what changes are needed in the vMCP proxy layer to support SSE reliably in a multi-pod environment.
• Consider whether SSE needs a separate persistence/replay mechanism or whether graceful drain on pod shutdown is sufficient.
• Ensure elicitation and any other SSE-dependent MCP features work correctly end-to-end.

References

• Current session affinity implementation uses Redis with GETEX + TTL.
• Streamable-http routing is tested with sessionAffinity: none.
• SSE path has not been fully tested/validated.