mcp: avoid panicking when a resource handler returns nil

[latent-9]

What

readResource dereferenced the handler's result before the if res == nil
check that was meant to guard it. A ResourceHandler returning (nil, nil)
therefore panicked instead of returning an error:

• modern clients: handleMultiRoundTripResult calls res.setResultType on the
  nil result, and
• older clients: res.setDefaultCacheableValues() runs on the nil result.

Either way the if res == nil guard a few lines below was dead code.

Why it matters

Request handlers run in their own goroutine and nothing recovers, so the panic
does not just fail the one request. It terminates the whole server process and
every concurrent session.

The sibling handlers already avoid this: callTool and getPrompt both guard
their result with if err == nil && res != nil before touching it, so a
(nil, nil) return flows up and becomes a normal error response.

Change

Move the nil check in readResource ahead of handleMultiRoundTripResult and
setDefaultCacheableValues, so a nil result returns the existing descriptive
error (read handler returned nil information) instead of panicking. Added a
regression test that drives a resource handler returning (nil, nil) through
the server and asserts a clean error.