fix(transport): propagate real clientInfo to peer_info in stateless mode

[github-gregory-bougeard]

Summary

Fixes #1172.

In stateless streamable-HTTP mode (StreamableHttpServerConfig::legacy_session_mode = false), peer_info_for_stateless_request reconstructs a synthetic InitializeRequestParams for every request so context.protocol_version() works inside handlers. It correctly reconstructs the protocol version, but always set client_info/capabilities to Implementation::default()/ClientCapabilities::default() — even for the literal initialize request, whose body does contain the real clientInfo.

That placeholder is exactly what Peer::peer_info() returns, and exactly what serve_inner logs via tracing::info!(?peer_info, "Service initialized as server") — so every real client (Claude Code, Gemini CLI, custom clients, ...) shows up identically as client_info: { name: "rmcp", version: "<sdk version>" } in server-side logs in stateless mode, regardless of what they actually sent. Any handler reading context.peer.peer_info() sees the same placeholder, even though the initialize handler's own typed request argument correctly carries the real value.

Fix

For the initialize request specifically, the full InitializeRequestParams is already available in the request body — this PR uses it verbatim instead of only extracting protocol_version out of it. Non-initialize requests are unchanged: there's no session in stateless mode to recover the original handshake from, so they still fall back to the placeholder for client_info/capabilities (only protocol_version is reconstructed, from the MCP-Protocol-Version header).

fn peer_info_for_stateless_request(
    request: &crate::model::JsonRpcRequest<ClientRequest>,
    headers: &HeaderMap,
) -> Option<InitializeRequestParams> {
    if let ClientRequest::InitializeRequest(ref init) = request.request {
        return Some(init.params.clone());
    }
    let version = headers
        .get(HEADER_MCP_PROTOCOL_VERSION)
        .and_then(|v| v.to_str().ok())
        .and_then(|s| serde_json::from_value(serde_json::Value::String(s.to_owned())).ok())
        .unwrap_or(ProtocolVersion::V_2025_03_26);
    Some(InitializeRequestParams {
        meta: None,
        protocol_version: version,
        capabilities: ClientCapabilities::default(),
        client_info: Implementation::default(),
    })
}

Testing

Adds crates/rmcp/tests/test_stateless_client_info.rs: spins up a real StreamableHttpService in stateless JSON-response mode with a handler that echoes both request.client_info (the handler's typed argument) and context.peer.peer_info().map(|p| p.client_info) (what serve_inner logs) back via InitializeResult::instructions, sends a real initialize request with a distinctive clientInfo, and asserts both match the client's real identity.

• Fails against the pre-fix code (peer_client_info.name == "rmcp" instead of the real client name) — verified locally by reverting just the tower.rs change and re-running.
• Passes with the fix.
• Existing test_stateless_protocol_version.rs and test_stateless_server_requests.rs (same module) still pass unchanged — this change doesn't touch the protocol-version reconstruction, only threads through capabilities/client_info alongside it for the initialize case.
• cargo clippy -p rmcp --features server,client,transport-streamable-http-server,reqwest --lib produces the same pre-existing warning set as main (verified via git stash diff), no new warnings from this change.
• cargo +nightly fmt -p rmcp -- --check clean.

Scope

Deliberately narrow: only the initialize branch changes. Non-initialize requests in stateless mode still can't recover the original client identity (no session to persist it in), so their client_info/capabilities placeholder is unchanged — fixing that would need a broader design discussion (e.g. an explicit "this peer_info is synthetic" marker, or per-request capability propagation per SEP-2575) that felt out of scope for this fix.