Add logging support to local transport used for proxy

[ooojustin]

Adds support for the notifications/message method from the official MCP spec to support sending custom logs to the mcpProxy client, independent of the ones relayed from the server.
It is currently used in connectToRemoteServer to send information which was only logged via console, so that clients have the ability to display status and react to different scenarios.

Using a simple callback from the official SDK in a custom client:

async def _logging_callback(
    params: LoggingMessageNotificationParams,
) -> None:
    logging.info(f"({params.level}) {params.data}")

You can see the connection logs reflected in the following output:

[info] Connecting to MCP server: log_test
[info] Server parameters: command='node' args=['C:\\Users\\justi\\OneDrive\\Documents\\Programming\\mcp-remote\\dist\\proxy.js', 'http://127.0.0.1:8888/sse'] env={} cwd=None encoding='utf-8' encoding_error_handler='strict'       
[info] Creating transport for server: log_test...
[info] Transport created for server: log_test
[info] Creating session for server: log_test...
[info] Initializing session for server: log_test...
--- calls the mcp-remote code here ---
[info] (info) {'status': 'connecting', 'message': '[40756] Connecting to remote server: http://127.0.0.1:8888/sse'}
[info] (info) {'status': 'connecting', 'message': 'Using transport strategy: http-first'}
[info] (error) {'status': 'error', 'message': 'Received error: Error POSTing to endpoint (HTTP 405): Method Not Allowed'}
[info] (info) {'status': 'reconnecting', 'message': 'Recursively reconnecting for reason: falling-back-to-alternate-transport'}
[info] (info) {'status': 'connecting', 'message': '[40756] Connecting to remote server: http://127.0.0.1:8888/sse'}
[info] (info) {'status': 'connecting', 'message': 'Using transport strategy: sse-only'}
[info] (info) {'status': 'connected', 'message': 'Connected to remote server using SSEClientTransport'}
[info] Session initialized for server: log_test
[info] Successfully connected to MCP server 'log_test' with 1 tools
--- internal code to test the MCP and confirm normal logs are still relayed as expected ---
[info] Received message of type: MessageType.TEXT
finish_reason tool_calls
[info] Handling tool call: log_test_log_test
[info] (info) Initial log message # <- normal log relayed from remote MCP
[info] (info) Delayed log message # <- normal log relayed from remote MCP
[info] Successfully called MCP tool 'log_test' on server 'log_test'
finish_reason stop

[clouatre]

Thanks for the PR! Before we can consider merging, we need clarification on the use case:

Questions:

1. Which MCP clients actually consume notifications/message and display these logs? Can you demonstrate this working with Claude Desktop, Cursor, or other clients?
2. What problem does this solve that stderr logging doesn't address?

Concerns:

• This adds dual logging (transport + stderr on line 139), which conflicts with PRs #127 and #170 that aim to suppress stderr because it breaks IntelliJ and subprocess usage
• Adds complexity (StdioServerTransportExt class, extra parameter, structured data) without clear benefit
• No evidence that popular MCP clients actually use these notifications

Recommendation:
Unless you can show concrete client implementations that require this, stderr logging is simpler and sufficient for debugging. The project direction seems to be moving toward cleaner stderr management rather than duplicating logs via transport.

Can you provide examples of clients consuming these notifications and the specific scenarios where transport-based logging is necessary?