Clean up sessions after legacy initialize parsing fails #1357

Problem

A legacy Streamable HTTP initialize response can include an MCP session ID in
its response headers while its JSON or SSE payload is malformed or empty. The
client currently parses the initialize payload before its normal session
cleanup state is established. If parsing fails, the worker exits without
sending the bounded DELETE for the session that the server already created.

The same gap exists when Auto lifecycle discovery falls back to legacy
initialize.

Proposed direction

• Capture the raw session ID from a JSON or SSE initialize response before
  parsing it.
• Retain the headers that were actually used for that initialize request.
• If initialize parsing fails, run the existing bounded DELETE behavior before
  returning the parse error.
• On successful parsing and protocol negotiation, replace that provisional
  cleanup state with the normal negotiated session cleanup state.
• Cover both direct legacy initialization and discovery fallback.

This proposal is deliberately limited to initialize parse failures. Draft
#1267 introduces a broader run_session/outer-cancellation lifecycle and also
centralizes cleanup. The focused change would not copy that refactor, stalled
body handling, or its cancellation suite. I would be happy to fold the narrow
case into #1267 instead if that is the preferred direction.

Planned validation

Source-module transport tests would supply malformed and empty initialize SSE
streams carrying a raw session ID. Direct initialize and Auto fallback cases
would verify failure plus exactly one DELETE for that raw session.

Would maintainers prefer this focused fix as a separate PR or as a test and
delta on #1267?