internal/jsonrpc2: plumb cancellation cause through request context

[aha-jansen]

Closes #1100.

What

handleAsync in internal/jsonrpc2/conn.go reported why an in-flight request had been canceled by inspecting the connection-level s.writeErr, guarded by a TODO waiting on golang/go#51365:

// Only deliver to the Handler if not already canceled.
if err := req.ctx.Err(); err != nil {
    c.updateInFlight(func(s *inFlightState) {
        if s.writeErr != nil {
            // Assume that req.ctx was canceled due to s.writeErr.
            // TODO(#51365): use a Context API to plumb this through req.ctx.
            err = fmt.Errorf("%w: %v", ErrServerClosing, s.writeErr)
        }
    })
    ...
}

That API shipped as context.WithCancelCause / context.Cause in Go 1.21, and this module already targets Go 1.25, so the TODO is now actionable.

This PR carries the cancellation cause on each request's context instead of inferring it from global state:

• incomingRequest.cancel becomes a context.CancelCauseFunc (built via context.WithCancelCause).
• The write-failure and read-side teardowns cancel each in-flight request with a cause wrapping ErrServerClosing.
• The remaining cancel sites (peer cancel via Cancel, normal completion) pass nil.
• handleAsync reads context.Cause(req.ctx) instead of looking up s.writeErr.

Why

Besides resolving the TODO, this fixes a latent mis-attribution. s.writeErr is connection-level state, not per-request: a request canceled for an unrelated reason (e.g. a peer cancel notification via Cancel) was reported as ErrServerClosing whenever s.writeErr happened to be non-nil at that moment. Tying the cause to the specific request's context removes that coupling.

ctx.Err() still returns context.Canceled in all cases, so external behavior is unchanged; only the reported cause becomes accurate and per-request.

Test plan

• go build ./...
• go test ./internal/... ./mcp/ (including the longer mcp integration tests) — all pass.
• Verified context.WithCancelCause semantics: with a cause, Err() stays context.Canceled while Cause() returns the wrapped ErrServerClosing; with nil, both resolve to context.Canceled — matching prior behavior.

Note

Per the discussion in #1100, the read-side teardown also carries a descriptive cause (wrapping ErrServerClosing) rather than a bare context.Canceled.

[guglielmo-san]

we should not assume this is an ErrServerClosing, it could be ErrClientClosing for example

[aha-jansen]

Good catch. You're right that the cancel cause is sent back to the peer, so the sentinel choice carries protocol semantics. I confirmed the two sites actually have different semantics: at 779 (local write failure) ErrServerClosing is reasonable; at 557 (reader EOF, most likely the peer disconnecting) it's indeed closer to client-side.

Which do you prefer: (a) switch 557 to ErrClientClosing, or (b) use the neutral underlying err without the server/client sentinel?

[guglielmo-san]

this should be fair for the new protocolVersion and stateless=true, as server initiated requests are not allowed

[guglielmo-san]

i don't think it is safe to remove the updateInFlight as it is performing shutdown-checks too

[aha-jansen]

I don't think the early shutting-down check is necessary here: the current incoming request is still being processed, so the connection isn't idle at that point, and the shutdown-advance branch (which only fires when s.idle() holds) can't trigger anyway. The effective check happens in processResult's own updateInFlight right after.