fix: reject changed duplicate initialize

[he-yufeng]

Summary

• reject a second initialize request if it tries to change the session's client parameters
• keep the first client_params intact so later capability checks cannot be spoofed by a duplicate handshake
• add a regression test covering the changed-params path

To verify

• uv run pytest tests/server/test_session.py -q -k "duplicate_initialize or server_session_initialize"
• uv run ruff check src/mcp/server/session.py tests/server/test_session.py
• uv run pyright src/mcp/server/session.py tests/server/test_session.py
• uv run python -m py_compile src/mcp/server/session.py tests/server/test_session.py
• git diff --check

Closes#2605

[he-yufeng]

Rebased this PR onto the current runner/connection architecture instead of keeping the old ServerSession._received_request patch. The duplicate-initialize guard now lives in ServerRunner._handle_initialize(), so a second initialize with changed params returns INVALID_PARAMS and leaves the original connection.client_params intact.

Validation:

• python -m py_compile src\mcp\server\runner.py tests\server\test_runner.py
• uv run pytest tests/server/test_runner.py -q -k "initialize" --basetemp .tmp\pytest-2606-20260610 -p no:cacheprovider (16 passed)

[he-yufeng]

Rebased onto current main and resolved the conflict in _handle_initialize: the duplicate-initialize rejection now layers on top of the new opts resolution (the create_initialization_options() fallback) instead of the old assert self.init_options is not None. test_runner_rejects_changed_duplicate_initialize still passes against the rebased base.

[he-yufeng]

Bumping this. A second initialize with changed params can still shift session state after the handshake, so rejecting the changed duplicate keeps initialization once-only per the spec. Rebases cleanly on main if there is interest.