fix(env): do not use symlinks on Windows, matching stdlib venv

[kishansaaai]

Fixes #1175

Description

In build 1.6.0, PR #1118 fixed the destination path in _fs_supports_symlink() (dest = f'{tmp_file}-b' -> f'{tmp_file.name}-b'), which previously caused the probe to always fail on Windows. Consequently, on Windows systems with Developer Mode enabled (including GitHub Actions Windows runners), _fs_supports_symlink() began returning True.

This caused venv.EnvBuilder(symlinks=True) to be used on Windows. On Windows, symlinked Python executables (such as in Conda and standard Python installations) break runtime DLL resolution (e.g. ImportError: DLL load failed while importing _ctypes) because the Windows loader resolves dependent DLLs relative to the symlink executable in Scripts/ rather than the base installation directory. This caused Windows build failures across projects such as XGBoost, LightGBM, and PartCAD.

In the standard library venv, symlinks defaults unconditionally to os.name != 'nt':

parser.add_argument(
    '--symlinks',
    default=(os.name != 'nt'),
    action='store_true',
    dest='symlinks',
    help='Try to use symlinks rather than copies, when symlinks are not the default for the platform.',
)

The stdlib venv never probes symlink support on Windows. As noted by @henryiii in #1175:

"#1118 fixed the symlink probe, but I think we should not have been probing in the first place. The comment said it was trying to match the stdlib, but the stdlib doesn't probe."

Changes

• In src/build/env.py, simplify _fs_supports_symlink() to return os.name != 'nt', matching stdlib venv.
• In tests/test_env.py, update tests to verify _fs_supports_symlink() returns True for POSIX and False for Windows (nt).
• Add changelog bugfix fragment docs/changelog/1175.bugfix.rst.

[layday]

Duplicate of #1176.