fix: dispatch first non-initialize request from the service loop

[DaleSeo]

Fixes #1261.

Motivation and Context

When a client skips initialize and server/discover and sends something like tools/call as its very first message over stdio, serve_server_with_ct_inner used to await the handler inline before starting serve_inner. Peer::send_notification, and therefore notify_progress, notify_logging_message, and similar methods, waits on a oneshot. That oneshot is resolved only when the loop drains peer_rx and writes to the transport. So if the handler sent a notification before returning, it blocked forever, and the client never received either the notification or the response.

The fix passes the pre-read request to serve_inner through a new initial_messages parameter. This seeds the loop's existing batch_messages queue. The request is dispatched in wire order before anything else is read from the transport, while the loop is already draining peer_rx. As a result, the first request now gets the same things as every other request handled by the loop, including a local_ct_pool entry so notifications/cancelled works, and the ORIGINATING_REQUEST task-local scope.

How Has This Been Tested?

Added tests

Breaking Changes

None.

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