feat(server): expose client implementation and capabilities to handlers

[jskjw157]

Adds clientImplementation and clientCapabilities properties on ClientConnection, delegating to what ServerSession already tracks during the initialize handshake.

closes #552

Motivation and Context

Server handlers (tools, prompts, resources) currently have no first-class way to read the connected client's name/version or advertised capabilities. The only workaround is to extract the full ServerSession from the Server instance via sessionId — awkward, and easy to get wrong. This blocks two real use cases:

• Adapting handler behavior for known client-side quirks
• Gracefully falling back when a capability (sampling, roots, elicitation) is not advertised, instead of letting createMessage/listRoots/createElicitation fail with a non-specific IllegalStateException

How Has This Been Tested?

Integration tests in ClientConnectionTest assert both properties are populated inside tool, prompt, and resource handlers (matching the existing callAllMethods pattern that exercises every ClientConnection member).

./gradlew :integration-test:jvmTest --tests "*ClientConnectionTest"
./gradlew :kotlin-sdk-server:apiCheck
./gradlew :kotlin-sdk-server:detekt :integration-test:detekt
./gradlew :integration-test:ktlintCheck

Breaking Changes

None for consumers. Adds two abstract members to ClientConnection, which would require any external implementer to recompile — but ClientConnectionImpl is the only implementation and is internal.

A small naming note: clientImplementation matches the MCP spec's clientInfo: Implementation field as suggested in the issue. This creates temporary dual naming with the existing ServerSession.clientVersion (also an Implementation). Renaming ServerSession.clientVersion is a wider public-API change, so I left it as a follow-up unless maintainers want it bundled here.

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
• 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

[jskjw157]

@devcrocod when you get a chance — implements #552 by delegating to what ServerSession already exposes. The one open question is whether to consolidate the clientImplementation / ServerSession.clientVersion naming in this PR or leave it as a follow-up; happy either way.