Fix TaskAnalyzer path-resolution order and detect inverted compositions

[Copilot]

Work item (Internal use):

Summary

MSBuildTask0003 can generate GetAbsolutePath(Path.GetDirectoryName(path)), which throws for bare filenames. Existing inverted calls also go undiagnosed.

• Fixer: Resolve the original input before GetDirectoryName/GetPathRoot, including nested extractions.
• Analyzer: Add scope-aware MSBuildTask0015 with a swap fix; recognize root extraction from absolute paths as safe.

Directory.CreateDirectory(
    Path.GetDirectoryName(TaskEnvironment.GetAbsolutePath(TargetFile)));

Customer Impact

Prevents migration-generated ArgumentException for inputs such as "list.xml" and identifies previously accepted inverted calls.

Regression?

Existing analyzer/fixer gap, not a runtime regression.

Testing

Regression coverage for both extraction methods, aliases, named arguments, nested calls, nullable inputs, scope, lookalike methods, and Fix All.

Risk

Limited to the unshipped, opt-in analyzer; no runtime changes. The new warning honors existing scope settings. Fixes are withheld where swapping would break AbsolutePath consumers or introduce nullable-input warnings.

• Fixes TaskAnalyzer: code fix generates GetAbsolutePath(Path.GetDirectoryName(x)) and no diagnostic flags the inverted composition #14971

[dotnet-policy-service]

Hello @copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.