Reject symlinks and hardlinks on Windows when opening .part files

[gistrec]

Problem

The POSIX receiver already refuses a pre-planted symlink (O_NOFOLLOW) and hardlink (st_nlink == 1) at the predictable <name>.part path (#32). The Windows path had no equivalent guard: it opened .part with CREATE_ALWAYS and no reparse-point handling. A local attacker who can write the receiver's working directory could therefore plant a reparse point or hardlink at the predictable <name>.part name and:

• redirect the receiver's writes to a victim file, and
• have CREATE_ALWAYS truncate the victim first.

Fix

openPartFile on Windows now mirrors the POSIX guard:

• CREATE_ALWAYS → OPEN_ALWAYS — never truncates an existing file before it is vetted.
• Open with FILE_FLAG_OPEN_REPARSE_POINT — opens the link itself, not its target.
• isLoneRegularFile(HANDLE) via GetFileInformationByHandle rejects a reparse point, a directory, or any file with nNumberOfLinks != 1, before any write — covering both fresh and --resume opens.

The check runs on the same handle used for writes, so there is no TOCTOU window between vetting and use.

Tests

• New run_symlink_part_test e2e case, mirroring the existing hardlink test: plants a symlink at <name>.part, then asserts the receiver exits non-zero and leaves the victim byte-for-byte intact.
• Full e2e suite + unit tests pass locally on macOS.

The Windows e2e job is skipped in CI (Winsock SO_REUSEADDR), so the new test pins the POSIX half of the guarantee; the Windows guard itself is exercised by the windows-latest compile job.

Notes

• README already documents this guarantee platform-agnostically (updated in [Security review][L3] Reject pre-planted hardlinks when opening .part files #32) — this PR makes that statement true on Windows.
• The FILE_ATTRIBUTE_DIRECTORY bit in isLoneRegularFile is defence in depth (CreateFileA without FILE_FLAG_BACKUP_SEMANTICS won't return a directory handle); a comment now explains why it stays.