Update FindSolutionFilesAtOrAbovePath to prioritize *.slnx over *.sln found in parent directories

[MichaelSimons]

Root Cause

The FindSolutionFilesAtOrAbovePath method in DotnetSlnPostActionProcessor used a two-pass strategy:

1. First, search the entire parent directory chain for *.sln files
2. Only if no .sln file is found anywhere up to the root, search for *.slnx

Since dotnet new sln now creates .slnx files by default, the *.sln search would walk all the way up from the output directory to the filesystem root. If a stale or unrelated .sln file existed in any ancestor directory (from parallel tests, other repos, the CI workspace, etc.), it would be returned instead of the .slnx in the output directory. When that transient file was subsequently deleted by another process between the search and the File.Exists validation in PathUtility.EnsureAllPathsExist, the error "Failed to add project(s) to the solution: File <path>.sln not found." occurred.

Additionally, on Windows, Directory.EnumerateFileSystemEntries(dir, "*.sln") can match .slnx files through the legacy FindFirstFile 8.3 short-name matching behavior. While .NET's managed filter usually rejects these, the behavior can vary across configurations.

Fix

Changed FindSolutionFilesAtOrAbovePath to search for both .sln and .slnx at each directory level before walking up to the parent. This ensures:

• A .slnx in the output directory is found immediately without searching ancestors
• .sln is still preferred over .slnx when both exist at the same level
• Explicit EndsWith filtering guards against Windows legacy glob matching

Testing

• All existing DotnetSlnPostActionTests pass (14 tests)
• Added new test AddProjectToSolutionPostActionPrefersNearbySlnxOverDistantSln that specifically verifies the fix: a .slnx in the output directory is found even when a .sln exists in a parent directory

Related to #54942

[baronfel]

I suspect the previous behavior was intended to be defensive - slnx have ben around for quite some time now and are a sibling of sln, it makes perfect sense to check for them at each 'level' and treat either one as a stop condition.

[Copilot]

Pull request overview

This PR fixes flaky dotnet new solution post-action behavior by changing solution discovery to prefer a nearby .slnx over an unrelated .sln found higher up the directory tree, aligning with dotnet new sln now producing .slnx by default.

Changes:

• Update FindSolutionFilesAtOrAbovePath to search for both .sln and .slnx at each directory level before walking up, ensuring nearer solutions win.
• Add explicit EndsWith filtering to guard against Windows legacy 8.3 short-name glob matching quirks.
• Add a regression test verifying a .slnx in the output directory is chosen over a .sln in a parent directory.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Cli/dotnet/Commands/New/PostActions/DotnetSlnPostActionProcessor.cs	Changes solution-file discovery to check .sln and .slnx per-directory level (preferring .sln only when co-located), avoiding distant-parent .sln selection.
test/dotnet.Tests/CommandTests/New/DotnetSlnPostActionTests.cs	Adds a regression test covering the “nearby .slnx beats parent .sln” scenario.