MCP server should respond to resource and prompt requests instead of dropping them

Summary

codex mcp-server currently recognizes MCP resource and prompt request variants, but the handlers only log and never send a JSON-RPC response. Clients that probe these methods can wait until timeout instead of receiving an empty result or a method-not-found error.

Evidence

Observed in local checkout /Volumes/VIXinSSD/codex-main at 2be9fd5a93.

In codex-rs/mcp-server/src/message_processor.rs:

• process_request routes ListResourcesRequest, ListResourceTemplatesRequest, ReadResourceRequest, SubscribeRequest, UnsubscribeRequest, ListPromptsRequest, and GetPromptRequest into handlers without passing the request id.
• The handlers at roughly lines 287-312 only call tracing::info!(...) and do not call outgoing.send_response(...) or outgoing.send_error(...).
• initialize advertises only tools, so not implementing resources/prompts is fine, but dropped JSON-RPC requests are still a bad failure mode for inspectors or MCP clients that probe optional methods.

Expected behavior

Either:

1. Implement the server-side resources/prompts surface, returning bounded results for resources/list, resources/templates/list, resources/read, prompts/list, and prompts/get; or
2. Return explicit JSON-RPC errors for unsupported resource/prompt/subscription methods.

The important part is that every request gets exactly one response.

Acceptance criteria

• A probe/inspector request to resources/list, resources/templates/list, resources/read, prompts/list, and prompts/get receives a response instead of hanging.
• codex-rs/mcp-server has regression coverage for unsupported optional MCP methods.
• The server capabilities remain accurate for whichever surface is implemented.