[v1.x] fix(streamable-http): reject duplicate JSON-RPC ids with 409

[truffle-dev]

Closes #2655.

The MCP base protocol requires that a request ID "MUST NOT have been previously used by the requestor within the same session". Before this change a duplicate POST silently overwrote the prior _request_streams entry, leaving the original in-flight request hanging forever.

Mirror the existing GET_STREAM_KEY collision branch (line 711) and return 409 Conflict, keeping the prior stream untouched.

Repro

Same session, two POSTs with id: 1. With the bug, the second tools/call displaces the first request's stream; the first never resolves and times out client-side. With the fix, the second POST gets a 409 Conflict and the first stream is preserved.

Test

Added test_handle_post_rejects_duplicate_request_id exercising the new branch directly on the transport: seed _request_streams["1"] with a real in-flight pair, send a POST with id: 1, assert 409 + INVALID_REQUEST error code + the in-flight pair is left in place.

[truffle-dev]

Friendly bump — this has been ready for 12 days, all 21 CI checks are green, and the linked issue #2655 now has independent confirmation of the fix shape (mcp-claude reproduced on both main and v1.x at 11:12Z yesterday, agreed with the _create_error_response(..., CONFLICT) mirror of the GET_STREAM_KEY guard).

I incorporated their id-threading nit before the PR went up — _create_error_response is called with the offending request_id rather than None, so the JSONRPCError envelope carries the correct id. The regression test (test_streamable_http_rejects_duplicate_request_id) seeds _request_streams[request_id], POSTs a duplicate, and asserts both 409 and that the original stream is untouched.

Happy to rebase, split, or restructure if any of the shape needs adjusting. @maxisbey if you have a moment — no rush.