[Sunrisepeak]

A native Windows mcpp cross build repeatedly failed to publish an atomic compiler status: the temporary source was a regular file, the destination was absent, and both replace and no-replace calls returned OpenKal invalid (condition 1). The build's status path lies beneath a preopened root through several components.

FILE_RENAME_INFORMATION receives a directory handle and a target name. Microsoft's documented relative-name form requires a simple file name under that handle. The old implementation passed the whole path beneath the preopen as FileName. This PR opens the target's parent through its supplied directory and sends only the leaf to NtSetInformationFile. The original supplied root still records the change; derived read-only rights are checked before renaming.

A new regression test covers a nested target, no-replace collision, and replacement. The MinGW build and Wine execution pass locally. The old implementation also passes this test under Wine, so native Windows CI is the qualification gate. The related mcpp diagnostic is mcpp #889, which is running a separate same-source comparison of OpenKal and the standard library. Version and release-chain updates follow only after native qualification.

Qualification update: A test-only branch with this exact regression test and the old backend passed native MSVC, LLVM/MSVC ABI, and GCC conformance (baseline run 42198019186). A nested target alone therefore does not reproduce the mcpp failure. This PR remains exploratory until the mcpp same-source probe identifies the additional condition. No version or release-chain change should be inferred from the current green test.

[Sunrisepeak]

The exact mcpp cross-build probe now narrows the failure beyond this PR's target-parent hypothesis: the temporary source is a regular file and the target is absent; OpenKal read of the source already returns invalid (1), both OpenKal rename forms return invalid, while std::filesystem::rename of the same source to a sibling succeeds. Source/target names resolve under the same preopen, with relative lengths 124/102. See mcpp CI 42201753772 and mcpp #889.

A nested destination alone also passed all three native Windows toolchain lanes on the unchanged backend (baseline CI 42198019186). The parent-handle change here does not address the observed read failure, so I am closing this exploratory PR. The remaining OpenKal/OS path or handle cause should be investigated from a standalone child reproducer and an uncollapsed NTSTATUS, without blocking mcpp's same-namespace transaction fix.