Reject listRoots early when the client has not initialized capabilities or does not advertise the roots capability, instead of sending an unsupported roots/list request.

Motivation and Context

Fixes #1067.

Other server-to-client operations already fail fast when the client does not advertise the required capability. McpAsyncServerExchange.listRoots(...) did not perform the equivalent check and could send a roots/list request to a client that does not support roots.

This change adds the missing capability validation and preserves the existing "Roots not supported" error behavior.

How Has This Been Tested?

Added regression coverage for:

• calling listRoots before client capabilities are initialized
• calling listRoots when the client does not advertise the roots capability
• verifying that no roots/list request is sent when either capability check fails

Targeted core tests pass locally:

McpAsyncServerExchangeTests
Tests run: 38, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

The existing roots capability integration tests were also verified successfully:

HttpServletStreamableIntegrationTests.testRootsWithoutCapability
PASS

HttpServletSseIntegrationTests.testRootsWithoutCapability
PASS

A full local test run still encounters two unrelated SSE/tool timeout failures:

HttpServletSseIntegrationTests.testToolListChangeHandlingSuccess
HttpServletSseIntegrationTests.testToolCallSuccess

Both failures were reproduced on a clean upstream/main worktree, so they are not introduced by this change.

Breaking Changes

No.

The change only adds fail-fast validation for an operation that requires the client to advertise the roots capability. Supported clients continue through the existing request path unchanged.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the [MCP Documentation](https://modelcontextprotocol.io)
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

The implementation follows the existing capability-checking pattern used by other server-to-client operations.

The production change is limited to McpAsyncServerExchange.listRoots(...), with corresponding regression tests in McpAsyncServerExchangeTests.

No documentation changes are required because this fixes SDK behavior to enforce the existing client capability contract.