Feature: Upgrade MCP SDK to v1.7.0 and adapt to stateless protocol

[rafaeljusto]

Description

The 2026-07-28 revision drops session-based architecture. The SDK negotiates the highest mutually supported version, so older clients keep working. Four fixes the bump required:

• request.ResponseWriter implements Flush/Unwrap, so the SDK's SSE writes through http.ResponseController actually flush instead of no-opping. Log capture is capped at 64 KiB; SSE streams made it unbounded.
• tools/list is marked cacheScope "private" — it is filtered per OAuth scope, and the SDK defaults cacheable results to "public".
• cmd/mcp-stdio drops its keepalive goroutine, which duplicated ServerOptions.KeepAlive and wrote id-less errors onto stdout.
• server/discover (SEP-2575) bypasses auth, as initialise already does.

Also pins MaxRequestBodyBytes to the 10 MB already enforced (the SDK default would tighten it to 4 MiB) and stops advertising the deprecated logging capability, which this server never honoured.

Stateless servers no longer echo Mcp-Session-Id and answer DELETE with 405; both are spec-permitted, and
MCPGODEBUG=allowsessionsinstateless=1 restores the old behaviour if a client needs it. See cmd/mcp-http/README.md.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Testing

• Tests pass locally (go test -v ./...)
• Added/updated tests for new functionality

Checklist

• Code follows project style guidelines
• Self-reviewed the code
• Added necessary documentation
• No new warnings or errors

[tw-garymeehan]

suggestion (non-blocking): scope the logging/setLevel claim to legacy revisions

cmd/mcp-http/README.md:160-162 currently tells clients:

The logging capability is no longer advertised. It was deprecated by
SEP-2577 and this server never sent a notifications/message, so nothing that
worked before stops working — logging/setLevel is still answered.

The last clause holds only for clients on pre-2026-07-28 revisions. In SDK v1.7.0, mcp/server.go:1880-1887 rejects methodSetLevel with CodeMethodNotFound whenever the negotiated revision uses the new protocol:

case methodInitialize, methodPing, notificationInitialized, notificationRootsListChanged, methodSetLevel, methodSubscribe, methodUnsubscribe:
    if validatedMeta.usesNewProtocol {
        ss.server.opts.Logger.Error("method removed in the new protocol", "method", req.Method)
        return nil, &jsonrpc.Error{
            Code:    jsonrpc.CodeMethodNotFound,
            Message: fmt.Sprintf("%q is not supported in the new protocol", req.Method),
        }
    }

Nothing breaks today, since clients still negotiate legacy revisions — but 2026-07-28 is exactly the revision this PR adds support for, so the README is wrong for the case it's introducing, and wrong in the direction that costs someone a debugging session.

Suggested wording:

• The logging capability is no longer advertised. It was deprecated by
  SEP-2577 and this server never sent a notifications/message, so no client
  loses functionality. Clients on pre-2026-07-28 revisions can still call
  logging/setLevel; on 2026-07-28 the SDK rejects it with -32601, as the
  revision removed the method.

For what it's worth, the internal/config/config.go comment already gets this right — it scopes the claim to "Old clients are unaffected". Only the README generalises it.