Windows: dx linker response file uses backslashes, clang eats them and fails cross-compiling to Android

Root cause is in the two places where dx writes linker arguments to disk on Windows:

- packages/cli/src/build/link.rs — the Windows command file writer, quotes each arg but does not normalize \ → / .
- packages/cli/src/cli/link.rs — the intermediate link_args_file writer, same issue.
- packages/cli/src/rustcwrapper.rs — the .o detection when reading such a file back needs to be aware of both separators.
Steps To Reproduce

1. Windows 10/11 host with Rust stable-x86_64-pc-windows-msvc toolchain and Android NDK 26.1.10909125 installed.
2. Add the x86_64-linux-android target: rustup target add x86_64-linux-android .
3. Create a Dioxus project that builds a native Android artifact (e.g. an android bundle) whose absolute paths contain multiple directory levels (typical Windows path like D:\work\... ).
4. Run the Android build via dx (uses dx.exe as the configured linker for the Android target).
5. The final linker invocation writes a response file with backslash paths; clang from the NDK parses it and fails with the "no such file or directory" errors shown above.
Expected behavior

dx should produce a linker response file that clang (the Android NDK's linker driver) can parse correctly on Windows, i.e. paths should not be corrupted by clang's backslash-escape handling. Concretely, on Windows the paths written into the response file should either use forward slashes ( / ) or have their backslashes properly escaped ( \\ ). Forward slashes are the simpler, safer fix since Windows accepts them as path separators.

Screenshots

N/A — full log is inlined above.

Environment:

- Dioxus version: main (built from source)
- Rust version: stable-x86_64-pc-windows-msvc (rustup)
- OS info: Windows 10/11 x64
- App platform: Android (native, cross-compile to x86_64-linux-android via NDK 26.1.10909125)
Questionnaire

I have a working fix locally that:

1. In packages/cli/src/build/link.rs , normalizes \ → / for every argument before writing the Windows response file:
2. In packages/cli/src/cli/link.rs , does the same normalization before writing link_args_file :
```
let args_to_write: Vec = if cfg!
(target_os = "windows") {
    args.iter().map(|arg| arg.replace('\\', "/
    ")).collect()
} else {
    args.clone()
};
std::fs::write(&self.link_args_file, 
args_to_write.join("\n"))?;
```
3. In packages/cli/src/rustcwrapper.rs , normalizes / → \ when scanning the command file for .o files so detection still works regardless of separator:
```
let normalized_line = line.replace('/', "\\");
let trimmed_line = normalized_line.trim().
trim_matches('"');
trimmed_line.ends_with(".o") || trimmed_line == 
"-flavor"
```
Happy to open a PR if the maintainers agree with this direction.

Start with the Windows response-file writers in packages/cli/src/build/link.rs and packages/cli/src/cli/link.rs, then inspect .o detection in packages/cli/src/rustcwrapper.rs. Reproduce the Android cross-compilation command on Windows, verify that clang accepts the generated response file, and confirm object-file detection still works with either path separator.

Written by the indexing model from the issue text.