feat(client): store full InitializeResult as server_params

[maxisbey]

ClientSession now stores the full InitializeResult via a server_params property, mirroring ServerSession.client_params. This provides access to server_info, capabilities, instructions, and the negotiated protocol_version through a single property.

Closes #1018. Supersedes #1565 and #2211.

Motivation and Context

Previously, ClientSession destructured only result.capabilities into _server_capabilities and exposed it via get_server_capabilities(). The other three InitializeResult fields (server_info, instructions, protocol_version) were discarded — users had to manually capture the return value of initialize(), which the high-level Client.__aenter__ throws away.

This PR aligns the client side with the pattern ServerSession already uses: store the whole params object, expose via a single property.

	ServerSession (existing)	ClientSession (this PR)
Stores	InitializeRequestParams	InitializeResult
Property	client_params	server_params
Access	session.client_params.capabilities	session.server_params.capabilities

The Go SDK, Rust SDK, and FastMCP all store the full init result; TS/C# destructure into per-field getters. This PR follows the same-codebase server-side precedent rather than cross-SDK mimicry.

How Has This Been Tested?

• test_server_params asserts None before init and all four fields (server_info, capabilities, instructions, protocol_version) after
• test_client_is_initialized updated to use client.server_params.capabilities
• ./scripts/test — 100% coverage, all pass
• pyright — 0 errors

Breaking Changes

• ClientSession.get_server_capabilities() removed → use session.server_params.capabilities
• Client.server_capabilities removed → use client.server_params.capabilities

Migration entry added to docs/migration.md under Breaking Changes, grouped with the other ClientSession changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Why server_params and not initialize_result? The server side says client_params, not initialize_request_params — the name describes what the data is (the server's params), not which RPC produced it. FastMCP uses initialize_result, but FastMCP is an external wrapper; it doesn't need to match our internal server↔client naming.

Why remove rather than deprecate? v2 rework — main is the clean-break branch. Carrying @deprecated shims into v2 means shipping with already-deprecated APIs.

_{AI Disclaimer}