projectGenerator (vs): crashes with STATUS_STACK_BUFFER_OVERRUN on addons containing symlinks

Summary

projectGenerator terminates with STATUS_STACK_BUFFER_OVERRUN (0xC0000409) when an addon
directory contains symlinks. No project is produced.

Reproduction

OF 0.12.1 (also 0.11.0, 0.11.2, 0.12.0), Windows 11, projectGenerator -p vs.

projectGenerator.exe -oC:\of0121 -pvs -a"ofxHapPlayer" C:\of0121\apps\myApps\test

Result: exit code -1073740791 (0xC0000409). The generated .vcxproj is an 11 KB skeleton
with 2 ClCompile entries and no addon content.

Isolated with a control:

So it is symlink handling specifically, not the addon and not PG generally.

The trigger

ofxHapPlayer ships 9 macOS .dylib version symlinks across two directories:

libs/ffmpeg/lib/osx/   libavcodec.57.dylib -> libavcodec.57.64.101.dylib   (8 links)
libs/snappy/lib/osx/   libsnappy.dylib     -> libsnappy.1.dylib            (1 link)

All nine resolve — no dangling links, no cycles — so this is not runaway recursion. And
MAX_PATH is not involved: the longest path in that addon is 103 characters, well under 260
(LongPathsEnabled=0 on this machine).

Note that renaming or moving libs/ffmpeg/lib/osx does not help: PG scans directories
regardless of name, and one of the nine lives under libs/snappy/lib/osx, a different tree.

Why it matters

Symlinks appear in any addon vendoring macOS dylibs, and they survive a git clone on Windows
when core.symlinks is enabled. The only workaround is deleting them, which breaks macOS
linking (libavcodec.dylib is expected to resolve to the versioned file) — so it cannot be
fixed in the addon without harming other platforms.

Verbose output ends while enumerating the osx directory:

[verbose] libswresample.dylib
[verbose] listed 12 files in "C:\...\ofxHapPlayer\libs\ffmpeg\lib\osx\"
<crash>

A 0xC0000409 fail-fast points at a fixed-size buffer in the directory walker rather than
stack exhaustion (which would be 0xC00000FD).