Make SSE stream management slightly more explicit for tasks

Author: LucaButBoring

docs/specification/draft/basic/utilities/tasks.mdx

@@ -412,7 +412,9 @@ stateDiagram-v2
 
 With the Streamable HTTP (SSE) transport, servers often close SSE streams after delivering a response message, which can lead to ambiguity regarding the stream used for subsequent task messages.
 
-Implementations have flexibility in how they manage SSE streams during task polling and result retrieval.
+Servers can handle this by enqueueing messages to the client to side-channel task-related messages alongside other responses.
+
+Servers have flexibility in how they manage SSE streams during task polling and result retrieval, and clients **SHOULD** expect messages to be delivered on any SSE stream, including the HTTP GET stream.
 One possible approach is maintaining an SSE stream on `tasks/result` (see notes on the `input_required` status).
 Where possible, servers **SHOULD NOT** upgrade to an SSE stream in response to a `tasks/get` request, as the client has indicated it wishes to poll for a result.