Pushed a test-only follow-up for the coverage gate. The HTTP mismatch path was already covered through the live server test, but that path runs out of process, so I added an in-process regression test for the 400 response branch.

Verified locally:

• .\.venv\Scripts\python.exe -m pytest tests\shared\test_streamable_http.py -q -k "protocol_version_mismatch"
• .\.venv\Scripts\python.exe -m ruff check src\mcp\server\streamable_http.py tests\shared\test_streamable_http.py
• .\.venv\Scripts\python.exe -m ruff format --check src\mcp\server\streamable_http.py tests\shared\test_streamable_http.py
• .\.venv\Scripts\pyright.exe src\mcp\server\streamable_http.py tests\shared\test_streamable_http.py
• git diff --check upstream/main..HEAD

Rebased this onto current upstream/main and resolved the StreamableHTTP in-process transport test refactor conflict.

The mismatch coverage is now in the current async in-process style, so the old socket/requests test shape was not brought back.

Validated locally on Windows:

• PYTHONUTF8=1 uv run pytest tests/shared/test_streamable_http.py -q -k "protocol_version_header or initialize_protocol_version_mismatch or backwards_compatibility_no_protocol_version" (5 passed)
• PYTHONUTF8=1 uv run ruff check src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• PYTHONUTF8=1 uv run ruff format --check src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• PYTHONUTF8=1 uv run pyright src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• PYTHONUTF8=1 uv run python -m py_compile src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• git diff --check upstream/main..HEAD

Follow-up after the Ubuntu matrix failure: the tests themselves passed, but strict-no-cover caught an old pragma: no cover on the request-header validation branch that is now covered by the updated in-process tests.

I removed that stale pragma and revalidated locally on Windows:

• PYTHONUTF8=1 uv run pytest tests/shared/test_streamable_http.py -q -k "protocol_version_header or initialize_protocol_version_mismatch or backwards_compatibility_no_protocol_version" (5 passed)
• PYTHONUTF8=1 uv run ruff check src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• PYTHONUTF8=1 uv run ruff format --check src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• PYTHONUTF8=1 uv run pyright src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• PYTHONUTF8=1 uv run python -m py_compile src/mcp/server/streamable_http.py tests/shared/test_streamable_http.py
• git diff --check upstream/main..HEAD

Rebased onto current main. Two things changed underneath this PR, so the resolution is non-trivial:

• The streamable-HTTP tests migrated from the requests/basic_server_url style to the in-process make_client(basic_app) async harness. I ported test_server_rejects_initialize_protocol_version_mismatch to the new style (kept the parametrized header/body mismatch cases).
• _validate_protocol_version was removed upstream, so the validation now hangs off _validate_initialization_request → _validate_initialization_protocol_version without reintroducing the old helper.

tests/shared/test_streamable_http.py passes in full (71 passed), including both mismatch cases.

Closing this one. The initialize / protocol-version handling has since been reworked upstream into the dual-era model (#2923 ignoring pre-2026 version pins, #3040 hardening the era-lock and its rejection path), which subsumes the narrow conflict rejection this PR added. Thanks for the direction on it, and happy to revisit if a gap turns up in the new model.