MCP drops stream resumability for task polling

MCP's latest spec update strips stream resumability from Streamable HTTP, per SEP-2575's July 28 changelog. That's a real risk for anyone running tool calls over flaky networks: the work just vanishes instead of picking back up.

The protocol used to reconnect a broken SSE stream with the Last-Event-ID header, replaying whatever messages the client missed. SEP-2575 removes that machinery, per the changelog.

Long-running work moves instead to the io.modelcontextprotocol/tasks extension. A server can hand back a task handle without being asked, and the client polls it with tasks/get until the job finishes. A new tasks/update method lets the client push more input into a task that's still running, something the old resumable-stream model never supported.

The changelog doesn't say what happens to clients still coded for the old reconnect behavior. A call that assumed the transport would resume it now needs its own retry logic, or it times out and the work is lost.