mcp: don't mutate caller params on multi-round-trip retries

[yhxlele]

Fixes #1144.

clientMultiRoundTripMiddleware calls setMultiRoundTripRetryParams(req, ...), which writes InputResponses and RequestState through the caller's params pointer and never clears them. A *CallToolParams (or GetPromptParams / ReadResourceParams) struct reused across calls then carries the first call's answers into the next call: a server gating on len(req.Params.InputResponses) == 0 — the idiom in this repo's own tests and examples — treats the fresh call as already answered, so the client's ElicitationHandler never fires and an elicitation-gated (e.g. destructive) tool runs without confirmation.

This change makes the retry loop carry the fulfilled responses and echoed state on a shallow copy of the params (multiRoundTripRetryRequest) instead of mutating the original request. Caller-owned params are now left untouched by CallTool, GetPrompt, and ReadResource. The server-side shim (serverMultiRoundTripMiddleware) is unchanged: the params it mutates are SDK-owned, decoded from the wire.

Tests: TestMultiRoundTrip_AutoRetryDoesNotMutateCallerParams (CallTool: params unchanged after the call, and reusing the same struct fulfills the input requests again instead of silently replaying the first call's answers — it failed with elicitations after reuse = 1, want 2 before the fix), plus GetPrompt/ReadResource analogues asserting params are left clean. All three fail on main and pass with this change; go test ./... and go vet ./... are clean.

Note on observable behavior: callers can no longer read the fulfilled responses off their own params struct after a call returns. That side effect was undocumented, and relying on it is exactly what makes the replay hazard above possible.

[yhxlele]

@guglielmo-san Both review comments have been addressed (the clone is merged into setMultiRoundTripRetryParams, and the default case now returns an explicit error) and the branch has main merged in. Whenever you have a moment for another look, mainly want to make sure it isn't waiting on anything from my side.

[guglielmo-san]

@yhxlele thank you for the contribution!