Preserve IIS temporary paths during uploads and directory import

[RabbiIslamRony]

PR Type

What kind of change does this PR introduce?

• Bugfix
• Security fix
• Improvement
• New Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• Text changes
• Other... Please describe:

Description

How to reproduce the issue or how to test the changes

1. On Windows/IIS, configure a custom File field in a directory and upload a valid file through the asynchronous listing-form uploader.
2. Confirm the raw temporary path, for example C:\Program Files\PHPv8.1\upload\phpAC39.tmp, retains every backslash before wp_handle_upload() and the upload succeeds.
3. Go to Directorist > Directory Builder, import a valid directory JSON file, and confirm the import succeeds without corrupting the uploaded temporary path.
4. Repeat both flows on a Unix host and confirm custom-file upload, directory import, and the existing listing-image REST upload still succeed.
5. Confirm nonce/capability checks, recursive cleaning, size restrictions, supported MIME validation, and WordPress upload validation remain active.

Verification completed:

• The reported Windows temporary path remained byte-for-byte unchanged; the previous wp_unslash() behavior reproduced the corruption.
• Unix temporary paths remained unchanged.
• LocalWP directory JSON multipart import succeeded with HTTP 200 and created the test directory.
• LocalWP asynchronous custom-field multipart upload succeeded with HTTP 201.
• LocalWP listing-image REST upload succeeded with HTTP 200.
• Both changed PHP files passed syntax checks and PHPCS with zero errors; the pre-existing warning count remained unchanged.
• git diff --check passed, and all temporary database, plugin, directory, field, and upload-file fixtures were removed.

Any linked issues

Fixes #1356

Checklist

• My code follows the WordPress coding standards

[RabbiIslamRony]

The PHPCS job stopped before code checkout because the current development-branch workflow still uses pull_request_target and actions/checkout refuses fork code in that privileged context. No project code or PHPCS command ran. The infrastructure failure is addressed by #2945; this check should be rerun after that PR merges. Both changed PHP files have zero PHPCS errors locally, with the pre-existing warning count unchanged.