[Nmd-sketch]

UTIL_isLink always returned 0 on non-POSIX platforms, and the Windows branch of UTIL_prepareFileList() had no reparse-point guard. As a result -r traversed junctions and symlinks found inside the input tree, combined with --rm this compressed and deleted files located outside the directory the user passed.

Added a _WIN32 branch to UTIL_isLink() querying GetFileAttributesA(), with the FILE_ATTRIBUTE_REPARSE_POINT test applied only when the lookup succeeds. Such entries are skipped in UTIL_prepareFileList() unless --follow-links is set, mirroring the POSIX branch, including its level-2 warning. Covered by a new playTests.sh test asserting that a junction (Windows) or symlink (POSIX) pointing outside the tree is left untouched by -r --rm

What and why
Fixes #4853.

After the fix the junction is skipped with
Warning : tree\link is a symbolic link, ignoring. Mirroring the existing POSIX behavior;
--follow-links still opts back into the traversal. The Windows path now costs one extra
GetFileAttributesA per listed entry, matching the per-entry lstat the POSIX branch has always done.

The new playTests.sh case creates a junction (Windows) or symlink (POSIX) pointing outside
the tree and asserts -r --rm leaves the outside file untouched. Verified both ways locally. Fails
without the fix (outside file compressed, original deleted by --rm), passes with it. Full CTest
suite passes.

Checklist

• I searched open pull requests and issues: this problem is not already being addressed.
• Bug fix: it comes with a reproducer or a test that fails without the fix.
• Performance change: numbers from repeated runs are included, with CPU, compiler, flags and data.
  A gain in one configuration is not a general gain: see the Performance section of CONTRIBUTING.md.
• I stated below whether AI or other automated tools were used.

Tools used

AI coding agent (Local LLM harness) was used to analyze the issue, draft the fix and write the tests.
All work was human-directed and reviewed and the failing-without-the-fix verification was done
locally on Windows with MSVC 2022. The issue report itself also disclosed AI-assisted analysis.

[Cyan4973]

Thanks for the fix and the test. #4905 builds on it: it keeps your test (you are credited as co-author), and restricts the check to symbolic links and junctions, because FILE_ATTRIBUTE_REPARSE_POINT alone also matches OneDrive placeholders and deduplicated files, which zstd would then skip even when they are named on the command line. Closing in favor of #4905.