fix: add panic recovery to goroutines that execute user code

[blackwell-systems]

Implementation for #958.

Problem

Library goroutines that dispatch user-provided handlers (tool handlers, middleware, etc.) lack defer recover(). A panic in user code crashes the entire host process.

As a library, the SDK doesn't own the process, doesn't control the supervisor, and doesn't know what else runs in the same address space. A panicking goroutine takes down the consumer's HTTP server, metrics exporters, graceful shutdown hooks, and any other in-flight work.

Fix

Add recovery to 5 goroutine sites:

File	Goroutine	Recovery behavior
internal/jsonrpc2/conn.go	handleAsync handler dispatch	Sends INTERNAL_ERROR JSON-RPC response to client
mcp/shared.go	keepalive goroutine	Logs via structured logger, goroutine exits
mcp/sse.go	SSE reader goroutine	Logs via slog.Default(), defer Close() still fires
mcp/streamable.go	handleJSON response processor	Calls c.fail() to signal connection error
mcp/streamable.go	handleSSE stream processor	Calls c.fail() to signal connection error
mcp/transport.go	stdio reader goroutine	Sends error on incoming channel

The critical path is handleAsync in internal/jsonrpc2/conn.go: this is where ALL tool, prompt, and resource handlers execute. A panicking tool handler currently kills the process; with this fix it returns an error response to the client and the server continues serving other sessions.

Tests

• TestToolHandler_PanicRecovery: registers a tool that panics, calls it, verifies process survives and error is returned
• TestToolHandler_PanicDoesNotAffectSubsequentCalls: panics one tool, then calls a different tool successfully, proving the server continues operating

Both tests crash without the fix (verified by reverting and running).

Notes

• Defer order is verified correct in all sites (LIFO semantics)
• go vet, -race, and full test suite pass
• Happy to adjust the approach based on feedback from Library goroutines lack panic recovery (9 goroutines can crash host process) #958

[guglielmo-san]

What is the threat this recover() is intended to address?
A recover() here wouldn't catch panics from user handlers since those execute on the goroutine spawned in handleAsync.

[blackwell-systems]

The recover is inside the go func() spawned by handleAsync (line 640), on the same goroutine that calls c.handler.Handle(ctx, req.Request). The full call chain from that goroutine is synchronous:

1. Handle → ServerSession.handle (server.go:1445)
2. ServerSession.handle → handleReceive (shared.go:157)
3. handleReceive → mh(ctx, method, req) (shared.go:171, comment: "mh might be user code")
4. mh → the user's tool handler

No additional goroutine is spawned between the recover and the user handler. jsonrpc2.Async(ctx) (called at server.go:1466) releases a concurrency semaphore so the next request can start being handled; it does not spawn a new goroutine.

The test TestToolHandler_PanicRecovery confirms: a tool handler calling panic("deliberate panic") is caught, the client receives an error response, and the process survives. Without the recover, that test crashes the binary.

[jba]

Please see my comment on #958. Recovering from panics is not the right approach for these sorts of faults.