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.

- [x] I have verified this does not duplicate an existing feature request