fix: run the Android llvm-ar probe in the caller's environment

[MohammedAlkindi]

Replaces #1867, which you approved but which went conflicted the moment #1866 squash-merged. Same commit, rebased onto main, now a single commit rather than three. Related: #1859.

I could not update #1867 in place because rebasing a pushed branch needs a force-push and my setup gates that on a human, so a fresh branch was the clean way to give you a mergeable version. Sorry for the extra PR number.

What broke

The Android branch of get_base_archiver_variant decides whether the NDK ships llvm-ar under that name by running llvm-ar --version, and it built that probe with a bare Command::new:

name = format!("llvm-{tool}").into();
match Command::new(&name).arg("--version").status() {

A bare name resolves through the ambient PATH, not the one Build::env set up, so a caller pointing PATH at its own toolchain gets the question answered about a different toolchain and cc falls back to the target-prefixed name.

This is the third site of the same root cause as #1859, after family detection and is_flag_supported, and it is the one that made clang_android unable to run here: the test puts llvm-ar on PATH through Build::env, the probe never saw it, and the fallback arm-linux-androideabi-ar is not there either, so cc's error path exited the process and took the whole test binary with it.

error occurred in cc-rs: failed to find tool "arm-linux-androideabi-ar": program not found

The change

The probe goes through set_ar_detection_env, so it inherits Build::env and gets its own recording class rather than consuming an out{i} slot. That is the third class we discussed on #1866, and it is why this is separate: it widens the design from two classes to three.

ProbeKind::ArDetection maps to CC_SHIM_OUT_FILES_FOR_AR_DETECTION, and Test gains collect_ar_detection_probes and get_ar_detection_probes alongside the other two. The fallback logic itself is untouched; only the environment the probe asks the question in changes.

Verified after the rebase, not before

Windows 11, x86_64-pc-windows-msvc, rustc 1.97.1, run against main at c5cc913:

tests/test.rs   59 passed, 0 failed, 0 ignored

That is the whole binary green in a single run. Before this change clang_android did not fail, it aborted the process, which is why the rest of that binary never reported.

Every other test binary green, doc-tests 28 passed, cargo clippy --workspace --all-targets -- -D warnings clean, cargo fmt --all --check clean, MSRV check -p cc on 1.65.0 clean.

The new assertion is test.get_ar_detection_probes(0).must_have("--version"), which fails on unmodified source because the probe never reaches the shim and no recording exists.

LLM usage, per the Rust policy: this change was developed with AI assistance (Claude). Adding this retroactively, since it should have been disclosed when the PR was opened.

[NobodyXu]

Thank you!

A new release will be cut this weekend