Notification stream routing: notifications/tasks/status goes to session SSE, not per-tasks/get SSE #346

Context

SEP-2663 commit ed4c83e (Apr 30) added:

In the Streamable HTTP transport, if a server sends this notification, it MUST send it on an SSE stream associated with a tasks/get request.

Current behavior

notifyV2TaskStatus uses bgCtx produced by core.DetachForBackground in taskV2Middleware. This swaps the dead POST-scoped notifyFunc for the session-level one wired by sseWiring on the persistent GET SSE stream. Notifications fan out on the client's long-lived GET SSE connection, NOT on any per-request POST SSE stream.

Gap

Strictly read, the spec requires holding open the SSE response from a tasks/get POST and pushing notifications there. This would require:

• Per-task SSE stream registry in the transport layer
• tasks/get hold-open semantics (keep the POST response open as SSE)
• Routing notifications to the specific tasks/get stream, not the session stream

Why this is not blocking

• Notifications reach the client correctly via the session stream
• v2-18 conformance passes
• No upstream conformance test checks which SSE stream carries the notification
• Single-node deployments (current reality) have no routing ambiguity
• The spec language was just added and may evolve

When to revisit

• Upstream conformance adds a transport-level stream routing test
• Multi-node deployments need per-task stream affinity for notifications
• The spec clarifies whether "associated with" means "the same POST response" or "the same session"