Rename MCPEXP002 Subclassing_* constants to Extensibility_*

[arimu1]

Summary

• Rename Experimentals.Subclassing_DiagnosticId, Subclassing_Message, and Subclassing_Url to Extensibility_* so internal naming matches MCPEXP002's actual scope (C# SDK extensibility APIs, not only subclassing).
• Update XML documentation and docs/list-of-diagnostics.md to describe MCPEXP002 consistently as experimental extensibility points in the C# implementation.
• Update all [Experimental(...)] call sites that referenced the old constants.

Fixes #1736

Notes

• Diagnostic ID unchanged: consumers continue suppressing MCPEXP002 as before.
• Message updated: the shared extensibility message now reads "This C# SDK extensibility API is experimental and subject to change." (RunSessionHandler keeps its dedicated message/URL constants).

Test plan

• dotnet build src/ModelContextProtocol.Core/ModelContextProtocol.Core.csproj — succeeded (0 warnings, 0 errors)
• dotnet build tests/ModelContextProtocol.ExperimentalApiRegressionTest/ModelContextProtocol.ExperimentalApiRegressionTest.csproj — succeeded
• Full solution dotnet build / dotnet test (not run here — disk space limited on build machine; mechanical rename only)

[PranavSenthilnathan]

I validated that the list of diagnostics is up to date with all experimental and obsolete diagnostic IDs currently defined by the SDK. Modulo the minor inline suggestions to clarify the purpose and expected lifetime of the MCPEXP002 extensibility APIs, this looks good.

Requesting changes so those documentation clarifications can be incorporated before merge.

Note

This review comment was generated with AI assistance.

[arimu1]

Applied all three suggestions verbatim in af6028d — thanks for the framing, "lets features ship in standalone packages without Core awareness" is a much better description of what MCPEXP002 is actually for than the old list-of-things wording.

Two things the new text drops that were in the old row, flagging in case either was intentional to keep:

• the #1363 link next to McpClient/McpServer subclassing
• the "consider using ConfigureSessionOptions instead" hint on RunSessionHandler

Happy to fold either back in if you want them retained. dotnet build on ModelContextProtocol.Core is clean (0 warnings).

[jeffhandley]

Thanks for tackling this, @arimu1!

[arimu1]

Rebased onto main (f41f2b7). Two Subclassing_* usages landed on main after this branch was cut and broke the build on the merge commit:

• McpServerRequestHandler.RoutingNameParameter (line 35)
• JsonRpcMessageContext.RoutingName (line 86)

Both are extensibility points in the same group as the enclosing McpServerRequestHandler attribute, so they now use Experimentals.Extensibility_DiagnosticId / Extensibility_Url like the rest. git grep Subclassing_ is empty across the tree, and dotnet build on the full solution is clean (0 warnings, 0 errors).