Add early long path validation to Windows build script

[pavelsavara]

On Windows machines without long path support enabled, the build fails in hard-to-diagnose ways deep in the build process.

This adds a check at the start of eng/build.ps1 that:

• Tries to create a temp file with a path exceeding 260 characters under artifacts/tmp/
• If that fails, exits early with a clear error message pointing to docs/workflow/requirements/windows-requirements.md#enable-long-paths and quick-fix instructions
• If it succeeds, writes a stamp file (artifacts/.long-path-validated) so subsequent builds skip the check

The check runs after -help and -subset help exit points so those still work without any filesystem access.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR adds an early preflight check in eng/build.ps1 to detect whether the machine can create files with paths longer than 260 characters, failing fast with guidance to enable long path support instead of failing later in the build.

Changes:

• Add Check-LongPathSupport to attempt creation of a >260-char temp file under artifacts/tmp/.
• On failure, exit early with instructions linking to the Windows requirements doc.
• On success, create a stamp file in artifacts/ to skip repeated checks.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[teo-tsirpanis]

Could we just check the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled registry key instead? This is the system-wide configuration required for long paths; the other is the app manifest entry, which has to be done in each of the tools used by the build. The script's check of writing of a file at a very long path is only checking if PowerShell supports long paths, which does not necessarily mean that other tools do. Hence my recommendation to remove it.