Deprecate misleading `ServerInfo` and `ClientInfo` aliases

[DaleSeo]

Problem

rmcp::model currently defines:

pub type ServerInfo = InitializeResult;
pub type ClientInfo = InitializeRequestParams;

These are SDK convenience aliases for the full initialization payloads. However, the 2026-07-28 protocol also uses serverInfo and clientInfo for identity metadata, where the value is Implementation.

Because of that, ServerInfo can easily be mistaken for the server identity, even though it includes the protocol version, capabilities, implementation identity, instructions, and metadata. The same issue applies to ClientInfo. This became especially noticeable when we aligned the discovery and result metadata in #1065 and #1078.

The naming collision is visible in several core paths:

// Subscription teardown added by #1078
let server_info = self.get_info(); // ServerInfo (InitializeResult)
let server_implementation = server_info.server_info; // Implementation

// Converting handler information into a discovery result
pub fn from_server_info(server_info: ServerInfo) {
    let ServerInfo {
        server_info, // Implementation
        // ...
    } = server_info;
}

// Building metadata for client discovery
let client_info = service.get_info(); // ClientInfo (InitializeRequestParams)
let implementation = client_info.client_info.clone(); // Implementation

In each case, the outer *_info value represents a complete initialization payload, while the inner field is only the implementation identity. The code is valid, but the repeated names obscure the distinction between the SDK aliases and the protocol metadata concepts.

Proposed migration

1. Deprecate ServerInfo in favor of InitializeResult, and ClientInfo in favor of InitializeRequestParams. Add notes to explain the metadata name collision.

2. Update the handler trait signatures, generated macro code, documentation, examples, and internal references to use the canonical schema type names.

3. Define the existing Default implementations using the canonical underlying types.

4. Keep the deprecated aliases for the rest of the 3.x release series, and remove them in the next major release.

The resulting public API would look roughly like this during the deprecation period:

#[deprecated(
    note = "use InitializeResult; ServerInfo can be confused with serverInfo metadata"
)]
pub type ServerInfo = InitializeResult;

#[deprecated(
    note = "use InitializeRequestParams; ClientInfo can be confused with clientInfo metadata"
)]
pub type ClientInfo = InitializeRequestParams;

pub trait ServerHandler {
    fn get_info(&self) -> InitializeResult;
}

pub trait ClientHandler {
    fn get_info(&self) -> InitializeRequestParams;
}

Because these are type aliases, existing downstream implementations that return ServerInfo or ClientInfo will remain type-compatible during the deprecation period. They will only receive warnings. This proposal does not change serialization or the wire protocol.

Alternatives

A protocol-independent ServerConfig and ClientConfig abstraction might eventually be a better way to describe local endpoint configuration, especially since stateless discovery now uses this information too. That would require a larger API design discussion, so we can consider it separately. For now, deprecating the misleading aliases is a smaller first step that directly addresses the confusion around identity metadata.

[DaleSeo]

@alexhancock @jamadeo Any thoughts?