Address asymmetry in McpServerHandlers/McpClientHandlers and make all filter properties settable

[Copilot]

Fixes asymmetries between server and client handler/options types and makes all filter properties settable for consistency.

Changes Made

• Seal McpClientHandlers: Now sealed to match the already-sealed McpServerHandlers, since both are configuration containers that shouldn't be subclassed.
• Add setter to McpServerOptions.Handlers: Now has get+set with null validation using Throw.IfNull, matching the existing McpClientOptions.Handlers pattern.
• Add setter to McpServerOptions.Filters: Now has get+set with null validation, consistent with the Handlers property.
• Add setters to McpServerFilters.Message and McpServerFilters.Request: Sub-container properties now follow the same settable pattern with null validation.
• Make all IList<T> filter properties settable: All 11 filter list properties in McpRequestFilters and both filter list properties in McpMessageFilters now have get+set with null validation, enabling both { ... } collection initializer syntax and [] collection expression syntax.
• Revert TestSseServer to use Handlers setter: Reverted TestSseServer/Program.cs to use options.Handlers = new() { ... } object initializer pattern to provide test coverage for completely replacing the McpServerHandlers instance.

All settable properties use the same field-backed lazy initialization pattern (get => field ??= new() or get => field ??= []) already established by McpClientOptions.Handlers.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[jeffhandley]

Before we merge the setters all back in, we need to get @halter73's review on this to make sure we don't have to restore the logic from here:

https://github.com/modelcontextprotocol/csharp-sdk/pull/1313/files#diff-dbe35ac96162daee9fdbec4c7b96a70c842ddeff0cd4943bfedcb84ffb0f280dL81

[halter73]

I'm fine making these both settable instead for maximum backwards compatibility. I still don't think we need to bring back any of the logic from OverwriteWithSetHandlers though.

This does technically make something order dependent that wasn't previously, but previously configuring McpServerHandlers in a configuration callback had the exact same ordering dependency with WithXXXHandler that configuring McpServerOptions now does. I also don't think this code exists or ever will exist that expect us to merge handlers added via WithXXXHandler and a completely overwritten McpServerOptions.Handler property, so I don't think it's worth adding back the complexity of OverwriteWithSetHandlers.

It might be worth reverting the changes we made to TestSseServer in #1308 though to make sure we still have test coverage for completely replacing the McpServerHandlers instance.

[halter73]

Should we also make all the IList of filters in McpRequestFilters and McpMessageFilters settable for maximum consistency?

I'm leaning towards yes, because otherwise I think you have to use the { ... } collection initializer syntax rather, but not the new [] collection expression syntax, and it'd be nice to be able to use both.

[stephentoub]

@copilot please address

[Copilot]

All 13 IList<T> filter properties (11 in McpRequestFilters, 2 in McpMessageFilters) are now settable with the same field ??= [] / Throw.IfNull pattern in 0ac9d64. Also reverted TestSseServer to use options.Handlers = new() { ... } to exercise the Handlers setter per @halter73's suggestion.