Windows build fixes for Bazel ≥ 9.0.1

[walter-zeromatter]

• bootstrap_process_wrapper.cc: rewrite @response-files to convert the rustc --sysroot= value to its 8.3 short form via GetShortPathNameA before spawning rustc. The MSVC link.exe shipped with VS 2022 BuildTools lacks longPathAware, so the resolved <sysroot>/lib/rustlib/.../libstd-*.rlib paths overflow MAX_PATH (260) and fail with LNK1181. Also restrict get_output_base to follow external/ only when it's a symlink (Bazel ≥ 9.0.1 made it a real directory on Windows).

• options.rs: same external-is-real-dir fix for the regular process_wrapper. Falls back to deriving output_base from current_dir's grandparent when external/ is not a symlink.

• main.rs: skip *.rcgu.{o,bc,bc.z} codegen intermediates when building the unified -Ldependency dir, and tolerate NotFound on the copy fallback. Pipelined sibling actions can garbage-collect those temporaries between read_dir and the hardlink/copy.

• cargo_build_script_runner/bin.rs: track exec_root symlinks for cleanup only when symlink_if_not_exists actually created the symlink (was hitting DirectoryNotEmpty trying to remove_dir real dirs created by runfiles staging, e.g. .github). Also skip .git from execroot symlinks so ring ≤ 0.17.x doesn't enter its "local hacking" mode that hardcodes ./target/tools/windows/nasm/nasm.

• cargo_build_script_runner/cargo_manifest_dir.rs: use symlink_metadata in remove_symlink so dangling directory symlinks (Bazel's local-spawn-runner.* sandboxes cleaned up before this runs) get remove_dir'd instead of failing remove_file with ACCESS_DENIED.

[dzbarsky]

@ArchangelX360 can you take a look at these and try them out?

[walter-zeromatter]

Triage: which of these patches are MSVC link.exe–specific vs. Bazel-9.0.1/pipelining-specific

Tested 2026-05-14 on Windows by swapping in the toml2json-style hermetic toolchain (ArchangelX360's toolchains_llvm_bootstrapped fork + windows_support@0.1.1 + rules_cc PR bazelbuild#561, --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1, --extra_toolchains=@llvm//toolchain:all). With that toolchain, C builds go through clang and linking through lld-link / rust-lld.exe — MSVC link.exe is never invoked. Full bazel build sdk:sdk succeeded with the 8.3-path conversion reverted.

So the patches split into two independent groups:

MSVC-link.exe-specific (obsoleted by hermetic LLVM/lld):

• bootstrap_process_wrapper.cc: the to_short_path / make_absolute / rewrite_response_file / rewrite_response_files logic and the <fstream> include. Premise was VS 2022 BuildTools' link.exe lacking longPathAware; lld-link and rust-lld handle long paths fine, so this is unneeded under a hermetic toolchain. Still needed for anyone resolving the auto-detected MSVC cc_toolchain.

Bazel ≥9.0.1 / pipelining-specific (still required regardless of C++ toolchain):

• bootstrap_process_wrapper.cc: get_output_base — only follow external/ when it's a symlink. Bazel ≥9.0.1 made it a real directory on Windows; canonicalizing external/.. otherwise yields the execroot, not the output base.
• util/process_wrapper/options.rs: same external/-is-real-dir fallback for the regular process_wrapper, deriving output_base from current_dir's grandparent.
• util/process_wrapper/incremental_cache.rs: find_output_base preferring an ancestor whose basename is not execroot. Bazel writes DO_NOT_BUILD_HERE in both the real output_base and execroot/ on Windows ≥9.0.1; without this, the path doubles to …/execroot/execroot/_main/….
• util/process_wrapper/main.rs: skip *.rcgu.{o,bc,bc.z} codegen intermediates and tolerate NotFound on the copy fallback. Pipelined sibling actions GC those temporaries between read_dir and hardlink/copy.
• cargo/private/cargo_build_script_runner/bin.rs: track exec_root symlinks for cleanup only when symlink_if_not_exists actually created them (was failing remove_dir on real dirs like .github from runfiles staging); skip .git so ring ≤ 0.17.x doesn't enter its "local hacking" hardcoded-nasm-path mode.
• cargo/private/cargo_build_script_runner/cargo_manifest_dir.rs: symlink_metadata in remove_symlink so dangling directory symlinks (Bazel's local-spawn-runner.* sandboxes cleaned up before this runs) get remove_dir'd instead of failing remove_file with ACCESS_DENIED.

If reviewers want, I can split the first bullet into its own PR and rebase this one to contain only the Bazel-9.0.1 fixes. Open question on whether the 8.3 path conversion is still worth keeping behind a feature flag for users on auto-detected MSVC.