[release/11.0.1xx-rc2] Fix dotnet test validation with explicit paths

[Evangelink]

[release/11.0.1xx-rc2] Fix dotnet test validation with explicit paths

Align no-separator MTP argument handling across .NET 10, RC2, and main.

Description

The exact #56338 scenario, where test application arguments follow --, is already fixed in .NET 11 RC2 by the separator-aware parsing backported in #56207. This PR does not change that behavior.

This PR instead backports the later explicit-build-path validation relaxation from #56375. Without --, Microsoft.Testing.Platform extension arguments are still forwarded as unmatched tokens. When an extension option value names an existing .csproj, .sln, or test module, RC2 can incorrectly treat that value as a non-first positional build path and emit a diagnostic asking the customer to use --project, --solution, or --test-modules even though one of those options is already present.

The change suppresses that misleading diagnostic only when an explicit build-path option has already selected the build input. Positional inference and duplicate build-path validation remain unchanged.

.NET 10 already contains the same no-separator behavior through #56374, so this change aligns .NET 11 RC2 with the merged .NET 10 servicing fix and main.

Coverage includes the end-to-end --project scenario with and without --, plus direct parser coverage for --project, --solution, and --test-modules in both forms.

RC2 still hosts this logic in MSBuildUtility.cs, so the merged TestCommandOptions.cs implementation was adapted there without changing behavior.

Related to #56338

Customer Impact

Customers using Microsoft.Testing.Platform extensions can pass existing project-, solution-, or module-like paths as extension option values consistently with or without -- when the build input is selected explicitly. The already-supported separator form is unchanged; this backport prevents valid no-separator invocations from failing with a misleading positional-path diagnostic.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

The change is narrowly scoped to suppressing a diagnostic only when an explicit build path is already present. Existing positional inference and duplicate build-path validation remain unchanged, and the implementation matches the merged main fix and the behavior already present in .NET 10 servicing.

Verification

• Manual

• Automated

• build.cmd -c Debug completed with 0 warnings and 0 errors.

• A focused dotnet.Tests run passed all 8 RC2 cases: two end-to-end --project variants and six direct parser variants for all three explicit build-path options with and without --.

• The release/10.0.4xx branch contains the !hasExplicitBuildPathOption validation guard and regression coverage with [InlineData(false)] and [InlineData(true)]; all [release/10.0.4xx] Fix dotnet test argument isolation after -- #56374 PR checks passed.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved blocking issues were identified.

Review effort: Lite
Findings: None

What changed in this PR

Ports explicit-build-path validation fixes to the RC2 dotnet test implementation.

Changes:

• Allows forwarded path-like arguments when explicit build paths are specified.
• Adds parser and end-to-end coverage with and without --.

File	Description
test/​dotnet.Tests/​CommandTests/​Test/​TestCommandParserTests.cs	Adds parser coverage for explicit build-path options.
test/​dotnet.Tests/​CommandTests/​Test/​GivenDotnetTestBuildsAndRunsTestsWithDifferentOptions.cs	Adds end-to-end project forwarding coverage.
src/​Cli/​dotnet/​Commands/​Test/​MTP/​MSBuildUtility.cs	Adjusts explicit build-path validation behavior.