Windows: use resolved destination path for atomic renames

[triplef]

This is a follow-up to #564, which unfortunately didn’t fully resolve the issue.

We were finally able to reproduce it by installing our app from the Microsoft Store onto an external drive. This then leads to the following error when user defaults are saved:

File NSData.m: 2151. In -[NSData writeToFile:options:error:] Rename ('\\?\D:\WpSystem\<UserID>\AppData\Local\Packages\<PackageID>\LocalCache\Local\<Company>\<App>\Preferences\gsbAC3B.tmp' to 'C:/Users/<me>/AppData/Local/<Company>/<App>/Preferences/<BundleID>.plist') failed - Error Domain=NSOSStatusErrorDomain Code=17 "The system cannot move the file to a different disk drive."

This happens because:

• Windows redirects writes under AppData to a private per‑user, per‑app location (virtualization). The app sees the normal AppData path, but the OS stores it in the package’s private store and merges it at runtime.
• Packaged apps can be installed on a PackageVolume on any drive, not just C:.
• Putting those together: if the package is installed on D:, the physical storage of the app’s private AppData is also on D: even though the logical path still looks like C:/Users/<me>/AppData/....

The fix:

Use the resolved destination path for atomic rename on Windows so temp file and final path stay on the same underlying volume, and update Windows fallback rename logic to operate on the resolved destination path.