Accept empty HTTP responses for one-way MCP messages

[raymond-openai]

Summary

• Treat an empty successful application/json response as accepted when the outbound JSON-RPC message is a notification, response, or error.
• Continue requiring response bodies for requests such as initialize.
• Add focused adapter coverage for response and error messages alongside the existing Streamable HTTP integration coverage for notifications and requests.

Addresses the empty-response transport failure in #20982. The separate silent codex exec error-surfacing behavior remains out of scope.

Testing

• just test -p codex-rmcp-client --no-capture (92 passed; one remote integration test required building the local codex binary)
• just test -p codex-rmcp-client --test streamable_http_remote streamable_http_remote_client_round_trips_through_exec_server --no-capture (passed after building the required binary; effective crate result: 93 passed)
• just fix -p codex-rmcp-client
• just fmt (Rust formatting completed; unrelated Python and Bazel formatter groups could not run locally because uv and dotslash are not installed)
• cargo fmt --all -- --check

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[raymond-openai]

I have read the CLA Document and I hereby sign the CLA

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 580ad22d3b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Handle empty replies for client responses too

When a Streamable HTTP server sends a request to the client, such as elicitation/create or openai/form, RMCP answers by posting a JsonRpcMessage::Response back through this same adapter. That response also does not expect a JSON-RPC reply, so a server that returns the same empty 200 application/json tolerated here for notifications still falls through to serde_json::from_slice(&[]) and fails the elicitation path. Treat client Response/Error messages as accepted on an empty successful body, or otherwise cover this no-reply message class before deserializing.

Useful? React with 👍 / 👎.