Use the 2025-06-18 elicitation capability shape

[abhinav-oai]

Why

Codex currently negotiates MCP 2025-06-18, where the client elicitation capability is represented as an empty object. We were still serializing capabilities.elicitation.form, which belongs to the later capability shape and can cause strict 2025-06-18 servers to reject initialize with an unrecognized-field error.

This keeps the handshake aligned with the protocol version Codex actually negotiates and fixes the compatibility regression tracked in #17492.

What

• Serialize the client elicitation capability as elicitation: {} for 2025-06-18.
• Keep elicitation advertised for both Codex Apps and custom MCP servers.
• Tighten regression coverage so the unit test asserts both the Rust value and the serialized wire shape.
• Add an app-server integration test that round-trips a form elicitation from a custom MCP server; the existing connector round-trip continues to cover the connector path.

Verification

• cargo test -p codex-mcp
• cargo test -p codex-app-server mcp_server_elicitation_round_trip
• cargo test -p codex-app-server mcp_server_tool_call_round_trips_elicitation

Next steps

• Decide whether tool_call_mcp_elicitation=false should also suppress capability advertisement during initialize.
• Revisit form / url capability advertisement when Codex is ready to negotiate MCP 2025-11-25, which defines that newer shape.

[mzeng-openai]

Can we make sure to test elicitations from connectors and custom MCPs and make sure they don't regress? For context they are supported it's just we don't advertise the mcp version as 2025-11-25