path.win32 normalize/basename/toNamespacedPath diverge from Node (drive-relative, trailing sep, UNC)

[proggeramlug]

Summary

path.win32.* diverges from Node on several Windows path edge cases (POSIX path is correct). Surfaced by the #800 node-core radar — test-path-normalize, test-path-basename, test-path-makelong fail on these once #1721 (require-binding) unblocked them.

All confirmed by running the inputs under both Perry and Node v25 (Perry < / Node >):

win32.normalize  "C:"                  => "C:"        (Node: "C:.")
win32.normalize  "c:"                  => "c:"        (Node: "c:.")
win32.normalize  ".\\"                 => "."         (Node: ".\\")          # trailing sep dropped
win32.normalize  "\\\\?\\C:\\"         => "\\\\?\\C:"  (Node: "\\\\?\\C:\\")  # long-path prefix trailing sep
win32.basename   "\\\\server\\share\\" => ""          (Node: "share")        # UNC share basename
win32.toNamespacedPath "\\\\server\\share" => "...UNC\\server\\share"  (Node: "...\\server\\share\\")

(toNamespacedPath('foo') also differs but is cwd-dependent — Node resolves relative paths against cwd first; lower priority.)

Root causes (path.win32 algorithm)

• Drive-relative root: normalize("C:") must yield "C:." (a bare drive letter is a relative ref to the drive's cwd, not the drive root).
• Trailing separator preservation: normalize(".\\") / "\\\\?\\C:\\" must keep the trailing separator when the input had one.
• UNC basename: win32.basename of a UNC root (\\server\share\) returns the share segment.

Notes

POSIX path.posix.normalize/basename/dirname/extname match Node across the full Node test-suite input set — this is isolated to win32. Niche for native compilation, but real for cross-platform code that calls path.win32 explicitly.

Context: follow-up to #1721; surfaced via #800.