feat: add ServerSession.NotifyElicitationComplete for url-mode elicitation

[1solomonwakhungu]

Summary

Add an exported ServerSession.NotifyElicitationComplete method so MCP servers can notify clients when an out-of-band URL-mode elicitation has completed.

Fixes #1091.

Background

The client side of the URL-mode elicitation flow already handles notifications/elicitation/complete through ClientOptions.ElicitationCompleteHandler and the URL elicitation middleware. However, servers had no exported API for sending that notification. The only available path required using unexported SDK internals, which prevented external server implementations from completing the flow.

Changes

• Add ServerSession.NotifyElicitationComplete with the same notification helper pattern used by ServerSession.NotifyProgress.
• Send ElicitationCompleteParams using the existing notificationElicitationComplete method constant and shared handleNotify dispatch path.
• Update the elicitation completion integration test to exercise the exported server API and verify that the client receives the matching elicitation ID.
• Preserve all existing notification behavior and protocol handling.

Test Plan

• go build ./...
• go test ./...
• go vet ./...

[guglielmo-san]

See comment #1091 (comment)

[1solomonwakhungu]

Thanks for the context, @guglielmo-san. You're right that notifications/elicitation/complete is removed in the 20260728 draft, and I agree we shouldn't expand the public API surface for a departing notification.

That said, users on the current protocol (20251125) have a real blocker today — there's no exported way for a server to complete a url-mode elicitation flow, and the client side already handles this notification. The issue reporter (Arcade) is running into this in production on v1.7.0-pre.2.

As a compromise, would you be open to keeping the helper but scoping it to the current protocol? A few options:

1. Document it as 20251125-only — keep the exported method but add a clear doc comment that it's for the current protocol and will be removed/deprecated when 20260728 lands. This unblocks current users without pretending it's a long-term API.

2. Unexported with a version gate — keep it unexported and only callable when the negotiated protocol is 20251125, so it can't be used accidentally against the new protocol.

3. Close this PR if the team prefers to handle the gap differently (e.g., a workaround in userland or waiting for 20260728 to ship). I'd want to make sure Arcade and other current-protocol users have a path forward first though.

Happy to adjust the PR in whichever direction you prefer. The goal is to unblock existing url-mode elicitation users without creating maintenance burden for the new protocol.

[1solomonwakhungu]

Thanks for the context, @guglielmo-san. I wasn't aware that this notification was removed entirely in protocolVersion 20260728. Given that, adding a public API for it doesn't make sense — I'll close this PR. Appreciate you looking into it.