Fix JsonSerializerOptions without TypeInfoResolver

[Copilot]

Passing JsonSerializerOptions without a TypeInfoResolver to McpServerTool.Create throws InvalidOperationException. Users expect this to work like standard JsonSerializer.Serialize methods which silently populate the resolver.

Based on review feedback from #1203 by @eiriktsarpalis.

Changes

• Add GetSerializerOptions helper in AIFunctionMcpServerTool that populates TypeInfoResolver from McpJsonUtilities.DefaultOptions when null, then calls MakeReadOnly()
• Add test verifying options without resolver work correctly

Example

// This now works (previously threw)
var options = new JsonSerializerOptions 
{ 
    PropertyNamingPolicy = JsonNamingPolicy.CamelCase 
};

McpServerTool.Create((string name) => $"Hello, {name}!", 
    new() { SerializerOptions = options });

// options.TypeInfoResolver is now populated
// options.IsReadOnly is now true

Co-authored-by: GeorgiPopovIT 69841500+GeorgiPopovIT@users.noreply.github.com

Original prompt

Please create a new PR with the commits from this PR (so the credit is still given) but then revising them based on the feedback in #1203 (comment)

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[stephentoub]

@eiriktsarpalis presumably there's a race condition here, where by the time we go to set TypeInfoResolver, it's already been set and/or the instance has already been made read-only? Is the right answer for that to a) just accept/document that concurrent use may result in such overwrites and b) catch whatever exception would emerge when trying to set this on an already read-only instance?

[eiriktsarpalis]

It's possible, although modifying the JSO while concurrently passing it to a serializer is a known source of errors and is not recommended. What bothers me most though is that this method could race with, say, JsonSerializer.Serialize which will try to assign it the default reflection-based resolver, or any other method that could try to set its own resolver following this convention.

[stephentoub]

What do you think we should do, @eiriktsarpalis ?

Is going back to the original solution of creating a clone JSO the least-bad option?