Forward server-to-client messages in the streamable HTTP proxy

[JAORMX]

Part of #5743 (Workstream B: 2025-11-25 compliance).

Gap

The Streamable HTTP proxy has no server→client channel: it returns 405 on GET (no standalone SSE stream) and drops all container→client notifications (pkg/transport/proxy/streamable/dispatcher.go — "Notifications are ignored for streamable HTTP"). Server-initiated flows — progress, resources/updated, */list_changed, sampling, elicitation — never reach clients over the modern transport. The legacy SSE proxy forwards them; the streamable one silently loses them.

Proposed work

• Implement the GET endpoint as a long-lived SSE stream per the 2025-11-25 transport spec (server MAY offer it; today we 405).
• Forward container-originated messages (notifications and server→client requests) to the appropriate client stream instead of dropping them.
• Keep 405 as a config option for servers that never push.
• Once notifications flow: re-apply tool filtering when tools/list_changed traverses the proxy, and verify tools/call gating uses a refreshed tool map (folded in from Re-apply tool filtering when tools/list_changed fires #5749).

Notes

• This unblocks re-filtering on tools/list_changed and vMCP backend-notification work.
• Design note: the 2026-07-28 revision replaces the GET stream with subscriptions/listen — keep the dispatch layer transport-agnostic so it can serve both.

Priority: High — protocol feature loss on our default transport.