fix: remove JSON-RPC ID type coercion for spec-compliant strict matching

[KeWang0622]

Summary

Remove the _normalize_request_id method that coerces string response IDs to integers. This restores spec-compliant strict ID matching as requested in #1795.

Problem

PR #1720 introduced automatic type coercion for JSON-RPC response IDs, allowing string IDs like "0" to match integer request IDs like 0. While this made the client more tolerant of non-compliant servers, it violates the JSON-RPC 2.0 and MCP specifications:

• JSON-RPC 2.0: Response ID "MUST be the same as the value of the id member in the Request Object"
• MCP Spec: Result/error responses "MUST include the same ID as the request they correspond to"

As @Kludex noted in #1795: "#1720 is not compliant" and "This should not be configurable!"

The coercion made request ID 1 and "1" interchangeable, which are semantically different values per the spec. Servers that echo back IDs in a different type are non-compliant and should not be worked around in the SDK.

Changes

src/mcp/shared/session.py:

• Remove the _normalize_request_id method entirely
• Use the response ID directly from the message without normalization

tests/shared/test_session.py:

• Update test_response_id_type_mismatch_string_to_int and test_error_response_id_type_mismatch_string_to_int to verify that type-mismatched IDs are now correctly rejected (request times out) rather than silently coerced
• The test_response_id_non_numeric_string_no_match test is unchanged since it already expected rejection

Verification

• uv run --frozen ruff format . — no changes needed
• uv run --frozen ruff check . — all checks passed
• uv run --frozen pyright src/mcp/shared/session.py — 0 errors
• uv run --frozen pytest tests/shared/test_session.py — 8/8 passed
• strict-no-cover — no pragma issues

Closes #1795