Sync AddIncomingMessageFilter_Intercepts_Request_Messages on initialized notification

The test asserts strict counts for both requests and notifications observed by
the incoming message filter, but ListToolsAsync only synchronizes on the
request/response exchanges (initialize, tools/list). The notifications/initialized
message in between is fire-and-forget on the client, and the server dispatches
each incoming message via McpSessionHandler.ProcessMessageAsync as a
fire-and-forget Task with a forced thread-pool yield. So the assertion can run
before the notification has even reached the filter pipeline, surfacing as
''Expected: 1, Actual: 0'' for the notification count.

Observed on Ubuntu/Release/net9.0 CI; reproduces under load on any target.

Apply the same TaskCompletionSource pattern already used by the immediately
following AddIncomingMessageFilter_Multiple_Filters_Execute_In_Order test:
set a TCS inside the filter when the InitializedNotification is observed,
and await it before snapshotting the counts.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: PranavSenthilnathan

tests/ModelContextProtocol.Tests/Configuration/McpServerBuilderExtensionsMessageFilterTests.cs

@@ -72,12 +72,23 @@ public async Task AddIncomingMessageFilter_Intercepts_Request_Messages()
     {
         List<string> messageTypes = [];
 
+        // The client sends notifications/initialized fire-and-forget, so unlike the initialize and
+        // tools/list request/response exchanges it has no synchronization point the test can await.
+        // Signal once the filter finishes processing it so the strict counts below observe a
+        // complete, stable log instead of racing the still-in-flight notification.
+        var initializedNotificationProcessed = new TaskCompletionSource<bool>(TaskCreationOptions.RunContinuationsAsynchronously);
+
         McpServerBuilder
             .WithMessageFilters(filters => filters.AddIncomingFilter((next) => async (context, cancellationToken) =>
             {
                 var messageTypeName = context.JsonRpcMessage.GetType().Name;
                 messageTypes.Add(messageTypeName);
                 await next(context, cancellationToken);
+
+                if (context.JsonRpcMessage is JsonRpcNotification { Method: NotificationMethods.InitializedNotification })
+                {
+                    initializedNotificationProcessed.TrySetResult(true);
+                }
             }))
             .WithTools<TestTool>();
 
@@ -87,6 +98,10 @@ public async Task AddIncomingMessageFilter_Intercepts_Request_Messages()
 
         await client.ListToolsAsync(cancellationToken: TestContext.Current.CancellationToken);
 
+        // Wait for the fire-and-forget initialized notification to flow through the filter pipeline
+        // before snapshotting the counts; otherwise the strict counts below can race the notification.
+        await initializedNotificationProcessed.Task.WaitAsync(TestConstants.DefaultTimeout, TestContext.Current.CancellationToken);
+
         // The message filter should intercept JsonRpcRequest messages.
         // Use strict counts so a regression that invokes the filter pipeline more than once per
         // incoming message (analogous to the SendRequestAsync double-wrap regression on the outgoing