Improve SSE endpoint sessionId parameter handling

[akazwz]

Add dynamic query parameter separator for sessionId to handle endpoints with existing query parameters more robustly

This PR improves the URL construction when adding the sessionId parameter to endpoints by dynamically selecting the appropriate separator ('?' or '&') based on whether the endpoint already contains query parameters.

Motivation and Context

When constructing the endpoint URL with the sessionId parameter, the code needs to determine whether to use '?' or '&' as a separator. If the endpoint already contains query parameters (e.g., /messages?filter=all), we should use '&' to append additional parameters. Otherwise, if there are no existing query parameters (e.g., /messages), we should use '?' to start the query string.

This change ensures that the SSE endpoint URLs are correctly formed regardless of whether the original endpoint already contains query parameters, preventing malformed URLs in the SSE connection.

How Has This Been Tested?

Tested with various endpoint formats:

• Basic endpoints: /messages → /messages?sessionId=xxx
• Endpoints with existing query parameters: /messages?filter=all → /messages?filter=all&sessionId=xxx

Breaking Changes

None. This is a non-breaking change that improves the robustness of URL handling without requiring any changes to user code.

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

Additional context

The implementation uses a simple check for the presence of '?' in the endpoint string. While this approach works for standard endpoints, it has a limitation: it doesn't handle the edge case where '?' might be part of the path itself rather than a query parameter separator. However, this is an extremely rare case in practice, and the simplicity of the solution outweighs the benefit of handling such edge cases.