[MTP Integration Analysis] VSTestBridge still depends on internal test-module and TRX capability contracts

[Evangelink]

Summary

Beyond the already-known SerializableKeyValuePairStringProperty dependency, Microsoft.Testing.Extensions.VSTestBridge still depends on internal MTP contracts for both test-module discovery and TRX enablement. Those usages are additional IVT blockers for #7739.

Evidence

• src/Platform/Microsoft.Testing.Platform/Services/ServiceProviderExtensions.cs:150-151
  • internal static ITestApplicationModuleInfo GetTestApplicationModuleInfo(this IServiceProvider serviceProvider)
• src/Platform/Microsoft.Testing.Extensions.VSTestBridge/Requests/VSTestRunTestExecutionRequestFactory.cs:40-45
  • serviceProvider.GetTestApplicationModuleInfo(),
• src/Platform/Microsoft.Testing.Extensions.VSTestBridge/Requests/VSTestDiscoverTestExecutionRequestFactory.cs:46-51
  • serviceProvider.GetTestApplicationModuleInfo(),
• src/Platform/Microsoft.Testing.Extensions.VSTestBridge/Capabilities/IInternalVSTestBridgeTrxReportCapability.cs:8-10
  • internal interface IInternalVSTestBridgeTrxReportCapability : ITrxReportCapability
  • bool IsTrxEnabled { get; }
• src/Platform/Microsoft.Testing.Extensions.VSTestBridge/VSTestBridgedTestFrameworkBase.cs:79-82
  • _trxReportCapability is IInternalVSTestBridgeTrxReportCapability internalCapability ? internalCapability.IsTrxEnabled ...
• Related known blocker already in the same area:
  • src/Platform/Microsoft.Testing.Platform/Messages/SerializableKeyValuePairStringProperty.cs:6-8
  • src/Platform/Microsoft.Testing.Extensions.VSTestBridge/ObjectModel/ObjectModelConverters.cs:102-119

Why this is a real issue

#7739 is about treating extensions like third-party consumers rather than privileged in-repo friends. Even if SerializableKeyValuePairStringProperty is addressed, VSTestBridge still cannot cross that boundary because it currently needs an internal service (ITestApplicationModuleInfo) and an internal capability contract (IInternalVSTestBridgeTrxReportCapability). That means the IVT-removal work remains incomplete after the known PR-5 blocker is fixed.

Suggested resolution

Introduce public/shared contracts for the pieces VSTestBridge actually needs: a public way to identify the current test application module, and a public TRX capability shape that exposes enabled state without an internal cast. Then update the request factories / base class to depend on those public contracts and keep SerializableKeyValuePairStringProperty tracked separately.

Related issues

• IVT story for MTP and extensions #7739