Microsoft.Testing.Platform: emit public TestMethodIdentifierProperty and stop relying on the vstestProvider capability

[Evangelink]

This SDK opts into the MTP vstestProvider capability here: src/YoloDev.Expecto.TestSdk/TestApplicationHelpers.fs.

Background

When a test app runs in Microsoft.Testing.Platform (MTP) server mode (how Visual Studio Test Explorer talks to it), the VSTest bridge can expose test metadata to the IDE in two ways:

1. Legacy vstest.TestCase.* properties (e.g. vstest.TestCase.Id, vstest.TestCase.FullyQualifiedName), serialized via an internal SerializableKeyValuePairStringProperty key/value bag.
2. Public, structured property types — in particular TestMethodIdentifierProperty, which serializes to the well-known location.type / location.method / location.method-arity wire properties.

VS picks which path to consume based purely on the server-advertised vstestProvider capability. This adapter currently opts into vstestProvider (by registering VSTestBridgeExtensionBaseCapabilities, whose INamedFeatureCapability.IsSupported("vstestProvider") returns true), which forces VS onto path #1 — the legacy internal KVP.

The testfx / VS Test Explorer team is working to deprecate and remove that internal KVP and have all IDE metadata flow through public property types. MSTest has already moved off the vstestProvider path; NUnit and Expecto are the only two adapters still using it.

How MSTest does it (the model to follow)

MSTest does two things:

1. Emits the public TestMethodIdentifierProperty by overriding the bridge hook AddAdditionalProperties (which is virtual and empty by default) — see MSTestBridgedTestFramework.AddAdditionalProperties + GetMethodIdentifierPropertyFromManagedTypeAndManagedMethod. This is what lets VS recover namespace / class / method (navigation, grouping, FQN) without any vstest.TestCase.* KVP.
2. Opts out of vstestProvider by registering a capability that does not implement INamedFeatureCapability — see MSTestCapabilities. VS then routes MSTest through the public-properties path.

What we'd like here

Mirror MSTest:

1. Override AddAdditionalProperties in this adapter's bridged framework to add a TestMethodIdentifierProperty (namespace, type, method, arity) so the structured location.type / location.method properties are emitted.
2. Drop the vstestProvider opt-in once Enable sourcelink #1 is in place.

Caveats / things to coordinate

• Unlike MSTest, NUnit/Expecto don't have ECMA-335 managed names, and (for NUnit) the FQN encodes parameter values (Ns.Cls.Method(x: 1)) that TestMethodIdentifierProperty (method name + arity, no argument values) can't represent. Declaration-level identity (navigation/grouping) is fine from location.type/location.method; per-row identity should rely on the public TestNode.Uid (already unique per data row).
• Please don't flip off vstestProvider before the public path is lossless — the VS + testfx side changes that make VS consume everything from the public properties need to land first. Happy to coordinate sequencing so this doesn't regress navigation / Test Case association.

I'm on the testfx / VS Test Explorer side and glad to help with the change or review. Filing this so the dependency is tracked.