Enable package validation for the MCP extension packages

[jeffhandley]

Why

ModelContextProtocol.Extensions.Apps and ModelContextProtocol.Extensions.Tasks each opted out of NuGet package validation with:

<!-- New package with no published baseline yet -->
<EnablePackageValidation>false</EnablePackageValidation>

That was correct when the comment was written, but it is no longer true. Both packages have shipped 2.0.0 and 2.1.0 on NuGet.org, so a baseline exists. The opt-out left two shipping packages silently exempt from the ApiCompat breaking-change detection that every other shipping package in the repo gets.

What changed

Deleted those two lines from both .csproj files. Nothing else. Both projects now inherit EnablePackageValidation=true and PackageValidationBaselineVersion=2.0.0 from src/Directory.Build.props, which is where the baseline is already configured centrally for the other three packages. No per-project wiring and no new pattern was introduced.

No CompatibilitySuppressions.xml was added for either package, because neither needs one.

Validation

dotnet clean -c Release followed by dotnet pack -c Release completes with 0 errors and 0 warnings, producing all five packages. No CP0xxx diagnostics and no "Unnecessary suppressions found".

A clean pack alone would look identical if validation had silently no-op'd, so that was verified separately two ways:

• Microsoft.NET.ApiCompat.ValidatePackage.semaphore is now present under artifacts/obj/ for all five packable projects, including both extension packages. Previously it existed for only three.
• The 2.0.0 baseline nupkgs for both extension packages were restored into the global packages folder, which only happens when baseline validation is actually enabled.

So the clean result is a real signal: there are no breaking changes in either extension package between 2.0.0 and HEAD.

dotnet build succeeds with 0 warnings and 0 errors. dotnet test failures in this environment are pre-existing and unrelated: conformance tests cannot launch node_modules/.bin/conformance.cmd (npm dependencies not installed locally), and ClientIntegrationTests.CallTool_Stdio_MemoryServer shells out to the npx-based memory server.

Note for reviewers

PackageValidationBaselineVersion stays at 2.0.0 even though VersionPrefix is 2.1.0. That gap is intentional and is the steady state, not drift: the baseline pins to the last MAJOR release for the duration of the series and only moves when 3.0.0 ships. Bumping it to 2.1.0 would re-baseline the API surface against itself and discard the compatibility guarantee across 2.x.

Note

This pull request description was generated by GitHub Copilot.