Make supposedly unreachable code less reachable

[halter73]

When I removed IServerTransport, I combined StartSession and InitializeSession, but I should have moved the call to StartSession into the McpServer constructor so you don't run into the following "unreachable" exception from McpServer.SendMessageAsync and SendRequestAsync called after McpServerFactory.Create but before McpServer.RunAsync.

 ModelContextProtocol.Tests.Server.McpServerTests.Can_SendMessage_Before_RunAsync
   Source: McpServerTests.cs line 588
   Duration: 81 ms

  Message: 
System.InvalidOperationException : This should be unreachable from public API! Call StartSession before sending messages.

  Stack Trace: 
McpJsonRpcEndpoint.GetSessionOrThrow() line 126
McpJsonRpcEndpoint.SendMessageAsync(IJsonRpcMessage message, CancellationToken cancellationToken) line 51
McpServerTests.Can_SendMessage_Before_RunAsync() line 597
McpServerTests.Can_SendMessage_Before_RunAsync() line 604
--- End of stack trace from previous location ---

  Standard Output: 
| [2025-04-01T15:47:33] ModelContextProtocol.Server.McpServer Information: Cleaning up endpoint Server (TestServer 1.0)
| [2025-04-01T15:47:33] ModelContextProtocol.Server.McpServer Information: Endpoint cleaned up for Server (TestServer 1.0)

It's unusual to send a message before handling any client requests like the initialization request, which is why this wasn't caught by our earlier tests, but it's possible that something like a log is fired off as fire-and-forget message, and there's no reason that should cause any issues like the exception fixed by this PR.

[PederHP]

It's unusual to send a message before handling any client requests like the initialization request, which is why this wasn't caught by our earlier tests, but it's possible that the tools or prompts collection changing fired off a fire-and-forget message, and there's no reason that should cause any issues like the exception fixed by this PR.

The spec permits only one or two message types before initialization is complete (logging and one I can't remember). The logging one is odd because the spec shows elsewhere that logging messages shouldn't be sent until after the client makes a request to set logging level.

But if there's exceptions now more could happen, so even if it's nonsensical or not allowed the endpoints (still wish there was a better catchall for client and server) should be robust against it.

[halter73]

I'm not taking a principled stance in favor of supporting sending messages using IMcpServer before receiving the initialize notification. We could prevent sending messages until initialization is complete similar to how we don't give you an IMcpClient until McpClient.ConnectAsync receives an InitializeResult, but we've never blocked on this before.

This PR is not that ambitious. It's just preventing the regression I caused yesterday by moving InitializeSession out of the McpServer constructor in #160 which now makes it possible to get an exception that "should be unreachable from public API!"

If we want to make it easier to delay sending messages until receiving the initialization notification, we can do that in a follow up PR, but I don't think it's too important considering it's unusual for the server to send messages before handling some sort of action initiated by the client.

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
ModelContextProtocol	77%	68%	10261	➖
ModelContextProtocol.AspNetCore	89%	100%	15	✔
TestServer	62%	39%	609	➖
TestSseServer	91%	68%	255	✔
Summary	77% (12334 / 16047)	67% (3666 / 5512)	11140	➖

Minimum allowed line rate is 60%