Fix potential assembly mismatches for Microsoft.TestPlatform.ObjectModel

[Evangelink]

Pin Microsoft.TestPlatform.ObjectModel to the in-box vstest version.

Microsoft.Testing.Extensions.VSTestBridge (pulled in transitively by test projects using MSTest.Sdk/MTP) requests an older Microsoft.TestPlatform.ObjectModel than the in-box vstest shipped by Microsoft.TestPlatform.CLI. Because test projects build into the test SDK layout, that older ObjectModel (and the CoreUtilities / PlatformAbstractions assemblies in the same package) overwrites the newer in-box vstest assemblies, causing dotnet test (VSTest mode) to crash with MissingMethodException: RunConfiguration.get_CreateNoNewWindow.

With central package transitive pinning enabled, adding a PackageVersion entry pins the transitive ObjectModel to the in-box vstest version so the two stay in sync.

This is a standalone version of the change in #54952, branched from current main (which already contains the unrelated ToolPackageInstanceTests build-break fix), so it can land independently of that fork-based PR.

[Copilot]

Pull request overview

Pins Microsoft.TestPlatform.ObjectModel via central package management to the same version as the in-box Microsoft.TestPlatform.CLI, preventing transitive downgrade/overwrite scenarios in test SDK layout that can crash dotnet test due to VSTest assembly mismatches.

Changes:

• Add a central PackageVersion entry for Microsoft.TestPlatform.ObjectModel.
• Tie Microsoft.TestPlatform.ObjectModel’s version to $(MicrosoftTestPlatformCLIPackageVersion) to keep it aligned with in-box vstest.
• Document the rationale in Directory.Packages.props.

Show a summary per file

File	Description
Directory.Packages.props	Adds a central transitive pin for Microsoft.TestPlatform.ObjectModel to match the in-box Microsoft.TestPlatform.CLI version and avoid runtime mismatches.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 0

[Evangelink]

Closing as duplicate of #54952, which already contains this exact change. #54952's CI failure was an unrelated stale-base build break that has now been resolved by merging latest main into it.