Fix flaky SucceedsWithWarningOnLockedFile test

[MichaelSimons]

Summary

Fixes the intermittent SucceedsWithWarningOnLockedFile test failure tracked by #53870.

This test has been failing ~12 times per month on Windows CI (windows.amd64.vs2026.pre.scout.open), with the assertion Warnings.Count == 0 — meaning the expected IOException from the file lock was never thrown and no warning was logged by the task.

Root Cause Analysis

The test created a locked file using a relative path (SucceedsWithWarningOnLockedFile.dll) resolved against the process working directory. The GetDependsOnNETStandard task resolves reference paths via TaskEnvironment.GetAbsolutePath(), which combines the path with ProjectDirectory (captured from Directory.GetCurrentDirectory() at construction time).

When xUnit runs test collections in parallel (4+ threads sharing the same process), the working directory state can become unreliable. If the absolute path resolved by the task differs from where the test actually created the locked file, File.Exists() returns false and the task skips the file entirely — producing zero warnings instead of the expected IOException-triggered warning.

Additionally, on Windows CI machines, antimalware mini-filter drivers (e.g., Windows Defender) can interfere with file locking on newly created .dll files, potentially allowing a second file handle to open despite FileShare.None.

Changes

1. Use absolute paths in an isolated temp directory: Replace the relative-path file creation with TestAssetsManager.CreateTestDirectory(), which creates a unique temp directory with an absolute path. This eliminates any dependency on the process working directory.

2. Add lock-verification probe: Before running the task, a probe attempts to open the locked file with FileAccess.Read. If the probe succeeds (meaning the exclusive lock is not being enforced), the test fails immediately with a clear diagnostic message rather than proceeding to a misleading Warnings.Count == 0 failure.

3. Extend from SdkTest: The test class now extends SdkTest to use standard test infrastructure (TestAssetsManager).

Fixes #53870

[baronfel]

@MichaelSimons the TaskEnvironment should have an API that is intended to be used with parallel execution, like in test runners: https://github.com/dotnet/msbuild/blob/main/src/Framework/TaskEnvironment.cs#L49 Could you see if this API provides a pathway towards solving this issue as well? It's what the MSBuild team intended to be the user-facing solution for test runners.