mcp: keepalive logs an ordinary client disconnect at Error, drowning real failures

A client going away is the normal end of a session, and startKeepalive reports it at Error (mcp/shared.go:885, v1.7.0). On a long-running streamable-HTTP server that is nearly every session, so the level buries whatever else the server has to say.

Numbers from one shared daemon over 23 days and 4096 handled requests:

1285  level=ERROR, total
1281  msg="keepalive ping failed; closing session"
   4  actual failures (three of them a caller's own bad arguments)

So 99.7% of the Error records are clients that disconnected.

To reproduce: point a streamable-HTTP client at the server, POST a request, and do not hold the SSE stream open. The next ping fails and the session closes with consecutiveFailures=1 failureThreshold=1.

KeepAliveFailureThreshold from #982 does not help here. The transport is gone, so the retry fails the same way one interval later; the record moves, it does not go away.

The PR that added this line (#887) left notifySessions at Warn for a delivery failure (server.go:779), which is the same class of event: the session cannot be reached. The asymmetry looks unintended rather than deliberate, and Warn would match.

Related: #218 (the ErrorHandler this logging stands in for), #865, #887, #982, #900, #1204.

Start in mcp/shared.go:885 at startKeepalive and compare its disconnect logging with notifySessions in server.go:779. Reproduce the streamable-HTTP client disconnect described in the issue, then verify that ordinary session loss is logged at Warn while genuine keepalive failures remain distinguishable.