feat(mcp): support MCP 2026-07-28 input_required (MRTR / SEP-2322) tool calls

What problem would this solve?

MCP version 2026-07-28 removed server-initiated requests and MRTR (SEP-2322) is now the only channel for elicitation. A server that adopts that revision that asks for mid-call user input (confirmation of a change, disambiguation, credentials-free approval flows, etc.) becomes unusable from goose. My concrete case is MCP servers whose write tools return a preview and require an explicit user approval before applying and under 2026-07-28 that approval needs to be a MRTR elicitation round vs storing anything in an session (which I'd rather avoid regardless).

What would a good outcome look like?

goose completes input_required rounds on tools/call to facilitate HITL and other use cases. Specifically:

• fulfill the elicitation via the existing path, echo requestState exactly as presented, retry the original call, bounding on rounds to some sane default. Decline/cancel would end the call (vs more rounds), and
• goose negotiates 2026-07-28 with servers that support it (assuming opt-in at compile time), while remaining fully backward compatible with existing servers.

Possible approaches

Goose is almost there... the elicitation foundation (handler, approval manager, gui and tui) already exists and works for the legacy server-initiated pattern. What's missing is protocol plumbing that exists today in rmcp AND the ability to negotiate the latest protocol in order to use it what is exists.

I was able to validate the client-side capability exists in rmcp. rmcp 3.x carries MRTR type: bounded client with round driving capabilities. There is also automatic discovery with legacy fallback type lifecycle, so backwards compatibility does not need to be reinvented. goose's existing elicitation handler can handle the rounds (at least in my PoC with the plumbing implemented.

Is the goose policy on protocol version tied to the default version in the rmcp version locked in the goose release? I assume so, but hoping for some sort of opt-in here so we can choose to use a later protocol version, I this case 2028-07-28. I am aware that it is more than MRTR that needs to be considered before that would be a default, which is why I am asking for an opt-in feature vs declared or default support. I had an LLM do a quick audit on what else was missing and I realize there is work to do. But I do think there is good cause to allow users to opt in with the knowledge it isn't fully supported protocol wise.

Additional context

• #11020 (MCP Tasks unreachable) looks like a sibling of this issue with shared root causes: the tool-call path only accepts the plain CallToolResult shape (in that issue, CreateTaskResult hits the same unexpected-response error that InputRequiredResult hits in my case), and the client's protocol-version posture lags what servers need. A fix for the version negotiation and a more general handling on the result side in the tool-call path would serve both. I noticed that in v1.46.0 and main, the explicit old-version pin that #11020 cites appears to be gone and the remaining with_protocol_version call records the negotiated version rather than choosing one, so main and the v1.46.0 release offer rmcp's default 2025-11-25, while older releases carried the pin.

I've validated feasibility end-to-end on a branch (including the legacy-fallback behaviour against a current non-2026-07-28 server) and am happy to submit a PR if there is agreement on need.

• I have verified this does not duplicate an existing feature request