Bump modelcontextprotocol/go-sdk to v1.7.0

[yhxlele]

Upgrades the MCP Go SDK from v1.5.0 to v1.7.0 (protocol revision 2026-07-28 support) and adapts the generator, runtime, tests, and docs to the SDK's behavior changes. No public API of protomcp changes (one exported helper is added: protomcp.ElicitationState).

⚠️ Upgrade note: clients without an ElicitationHandler now get a hard error

The single largest user-visible change. A client calling an elicitation-gated tool without registering an ElicitationHandler:

	v1.5.0	v1.7.0
returned error	nil	calling "tools/call": multi-round-trip: fulfilling input request "confirm": client does not support elicitation
result	IsError: true, text client does not support elicitation	nil

The graceful, LLM-legible tool error becomes a JSON-RPC protocol failure that never reaches ToolErrorHandler. Clients using elicitation-gated tools must register an ElicitationHandler.

Elicitation moves to multi-round-trip input requests (SEP-2322)

ServerSession.Elicit fails on protocol ≥ 2026-07-28 sessions, so the generated confirmation gate now returns a CallToolResult carrying an elicitation InputRequest under the fixed key "confirm" and reads the client's answer from inputResponses on the SDK-driven retry. One generated shape serves both protocols: the SDK's client middleware fulfills the request via the existing ElicitationHandler on new sessions, and its server-side shim performs a classic elicitation/create round-trip for legacy sessions. All existing elicitation e2e tests pass unchanged; a new e2e_elicitation_legacy_test.go suite pins the server-side shim over HTTP/2025-11-25 (accept, decline, no-handler) with the client-side MRTR middleware disabled so the shim is exercised in isolation — it previously had zero coverage.

Answers are bound to the call that prompted them. The input-required result carries RequestState = protomcp.ElicitationState(toolName, rawArgs) and the retry must echo it back or the gate re-prompts. Without this, the SDK's in-place mutation of the caller's CallToolParams (setMultiRoundTripRetryParams) meant a client reusing one params struct across calls carried a stale "confirm" answer into the next call and silently skipped the confirmation — reproduced against the tasks example and now pinned by regression tests (TestDeleteTask_ElicitationReusedParamsRePrompts, TestDeleteTask_ElicitationPrePopulatedAnswerRePrompts). The binding is a content hash, not an authenticator: elicitation remains a UX confirmation for honest clients, not a server-enforced authorization control (a client could always fabricate an accept from its own handler). This trust boundary is now documented in the README.

Behavior deltas accepted with this design:

• gated handlers run twice per confirmed call;
• elicitation transport failures surface as SDK/client-side errors instead of flowing through ToolErrorHandler;
• ToolResultProcessors do not run on the input-required intermediate (the SDK rejects results carrying both Content and InputRequests), so the rendered confirmation prompt is not subject to redaction processors — documented, with guidance to keep sensitive values out of elicitation.message.

Cross-origin protection kept on by default

go-sdk v1.7.0 stopped installing cross-origin protection when StreamableHTTPOptions.CrossOriginProtection is nil (reproduced: the same cross-site POST returns 403 on v1.5.0 and 200 on a bare v1.7.0 bump) and deprecated the field. protomcp restores the v1.5.0 always-on default by wrapping its handler with http.NewCrossOriginProtection() unless the caller supplied their own instance via WithHTTPOptions. Tests cover default-on (403 cross-site / 200 same-origin), unrelated-HTTP-options-still-wrapped, and caller-supplied policies in both directions (trusted origin admitted, untrusted origin still 403) — the rejection leg guards against a future SDK release silently ignoring the deprecated field.

Other v1.7.0 changes absorbed (documented, no code)

• 4 MiB default request-body cap on the streamable HTTP transport (HTTP 413 above it); adjustable via StreamableHTTPOptions.MaxRequestBodyBytes.
• List-changed delivery split: sessions on ≥ 2026-07-28 receive list-changed notifications only over an opted-in subscriptions/listen stream (the go-sdk client opens it automatically when the matching handler is registered); a new-protocol client with no ResourceListChangedHandler silently stops receiving NotifyResourceListChanged. Legacy sessions are unaffected. SubscribeHandler/UnsubscribeHandler keep firing on both paths — subscriptions/listen routes through the same internal subscribe machinery.
• Error-code landscape: mcp.CodeResourceNotFound moved from const -32002 to a deprecated var at -32602. protomcp's own codes are unchanged (PermissionDenied → -32002 no longer collides with anything; -32602 is now shared between the SDK's resource-not-found/invalid-params and our invalid-cursor mapping).
• MCPGODEBUG escape hatches (enableoriginverification, allowsessionsinstateless, hintomitempty, customresnotfounderrcode, nowrapinvalidparams, noprotocolerrorbody, disablecontenttypecheck, disablecompleteparamsvalidation, disablelocalhostprotection): protomcp relies on none of them. enableoriginverification=1 is the SDK-side alternative to our cross-origin wrap.
• ToolAnnotations wire shape: readOnlyHint/idempotentHint are always serialized when Annotations is present (no longer omitempty).
• Generated resource-read handlers cannot hit the SDK's new nil-result deref (FinishResourceRead panics with an actionable message on a nil result first).

Verification

• go build ./... clean; full go test -race -count=1 ./... green
• golangci-lint run 0 issues; buf lint clean; buf generate drift-free; go mod tidy idempotent
• Existing in-memory suites (now negotiating 2026-07-28 via server/discover) and HTTP suites (pinned to 2025-11-25) pass without assertion changes

Follow-up (separate PR)

A stateless listen-based e2e example (Stateless: true + 2026-07-28 subscriptions/listen + PropagateRequestCancellation).

[jiachengxu]

I think we shouldn't skip here, since this PR still pins go-sdk v1.7.0 and modelcontextprotocol/go-sdk#1145 is still open, so this is the exact unsafe behavior we will ship. I changed this Skipf to an assertion locally and the replay only prompted once, then the second destructive call returned success without confirmation, could we wait for the fixed SDK release and pin it, and make this a hard failure before merging?