T15 - client MRTR (multi round trip request) retry loop

Target branch: 2026-07-28-protocol-support

Requires:

• https://github.com/softwaremill/chimp/issues/243
• https://github.com/softwaremill/chimp/issues/248

A chimp client completes a tools/call, prompts/get or resources/read that a 2026-07-28 server answers with an input-required result. The client gathers the requested input through its handlers and retries the request, as many rounds as the server needs. The caller sees one call and one final result.

Handlers

• The roots, sampling and elicitation handlers can be given to any client, over any transport. A bidirectional transport is needed only for legacy servers that send requests themselves.
• The capabilities the client declares on every request reflect the handlers it has. A server may therefore only ask for input the client can produce.

The retry loop

• When a result has resultType: input_required, the client answers every entry of inputRequests with the handler for its kind, then sends the original request again with all answers in inputResponses, under the same keys.
• The retry carries requestState byte for byte as the server sent it. When the server sent none, the retry carries none. The client never inspects or changes the state.
• The retry is a new request with a new id and its own request metadata.
• An input-required result without inputRequests leads to a retry with the state only.
• The loop continues while the server keeps asking, up to a bounded number of rounds. At the bound the call fails with McpProtocolException.
• A result without resultType is complete and ends the call. No retry happens.

Failures

• An input request of a kind the client has no handler for fails the call with McpProtocolException. Nothing is retried.
• A handler that fails or refuses ends the call with that failure. A handler that answers with decline or cancel produces a normal answer, and the server decides what happens next.
• An input-required result on any operation other than the three named above fails the call with McpProtocolException, because the spec forbids it.

Coverage

• The rules above hold for the sync and streaming clients, over HTTP and stdio, on ZIO, Ox and Pekko.
• Behaviour towards legacy servers does not change.
• The conformance client handles the sep-2322-client-request-state scenario, which calls test_mrtr_echo_state, test_mrtr_unrelated, test_mrtr_no_state and test_mrtr_no_result_type.

Spec:

• MRTR - Client Requirements
• MRTR - InputRequests
• MRTR - InputResponses
• MRTR - Supported Requests
• Basic - Result Responses
• Elicitation - Statefulness
• Elicitation - URL Mode Flow

Conformance scenarios that must pass after this task (2026-07-28 run):

• Client: sep-2322-client-request-state.

Docs: yes.

• docs/client/capabilities.md: the handlers work over every transport with a 2026-07-28 server, a bidirectional transport is needed only for legacy servers, how the retry loop behaves and where its bound is set. Updated McpClient.apply and bidirectional snippets.

Start with the sync and streaming client request-handling entry points across HTTP and stdio on ZIO, Ox and Pekko; the payload does not name implementation files. Run the Client conformance scenario sep-2322-client-request-state, including its listed test methods, and verify the retry, state, handler-failure and bound rules. Update docs/client/capabilities.md with the requested transport, retry-bound and snippet documentation.