Route application-sent notifications/resources/updated to matching subscriptions/listen streams #1930

Problem

On 2025-06-18 sessions a server announces a changed resource with
server.SendNotificationAsync(NotificationMethods.ResourceUpdatedNotification, new ResourceUpdatedNotificationParams { Uri = ... }),
and clients that called resources/subscribe receive it.

The 2026-07-28 revision (SEP-2575) replaces resources/subscribe with subscriptions/listen + resourceSubscriptions. In 2.2.0 the built-in listen handler fans out */list_changed only, and #1662 left resources/updated to a custom SubscriptionsListenHandler. A custom handler is a full replacement, so a server that only wants to announce resource updates must re-implement the acknowledgement, grant filtering, list_changed fan-out and cancellation that the built-in handler already does. The same server code therefore works for older clients and silently does nothing for 2026-07-28 clients.

Proposal

Let the built-in handler honour resourceSubscriptions, and route resources/updated the way SendListChangedNotificationAsync routes */list_changed:

1. In the acknowledgement, grant the requested URIs that the server can update (for example when ServerCapabilities.Resources.Subscribe is true, or through an optional filter callback).
2. When the server sends notifications/resources/updated for a URI, deliver it on every active subscription that granted that URI, over the subscription's RelatedTransport, tagged with _meta[MetaKeys.SubscriptionId].
3. Keep the current behaviour for pre-SEP-2575 sessions (resources/subscribe clients still get it on the session channel).

Application code stays the same across revisions: one SendNotificationAsync call reaches subscribers on both.

If changing the built-in handler is not wanted, an alternative is a public hook, for example McpServer.SendResourceUpdatedAsync(string uri) that does step 2 against the SDK's own subscription table.

Context

We hit this porting a server that pushes resources/updated for an auth://status resource when a user's session expires. Today we pin tests to 2025-06-18 and accept that 2026-07-28 clients learn about the expiry only on their next call.

Happy to contribute a PR if the direction is acceptable.