libz-sys build script leaks environment variables in the build directory

The build script of `libz-sys` version <= 1.1.30 prints the full environment of the build, including any secrets it contains, to its stdout when compiled with `cc@1.6.0` or later on a Unix host. This affects any build that depends on `libz-sys`. Cargo saves build script stdout under `target/`, so the values end up in anything that stores or shares the `target/` directory, such as CI caches. This is similar to the Miri issue. Details To decide whether to link against a system zlib, the `libz-sys` build script compiles a small test program with a compiler command from `cc` and logs it with: ```rust println!("running {:?}", cmd); ``` On Unix, `Debug` impl for `std::process::Command` prints every environment variable explicitly set on the command. Before `cc@1.6.0`, its `Tool::to_command()` set only a few compiler-specific variables. Starting with `cc@1.6.0` (released 2026-10-03), `Tool::to_command()` clears the environment and sets every variable explicitly. Cargo parses build script stdout for `cargo:` directives, and stores the full output in the build directory. It also prints it with `-vv`. The probe runs for a default `libz-sys` build, including when pkg-config finds zlib, unless one of these applies: • the target is Windows, Android, Haiku or OpenHarmony • static linking is requested via the `static` feature or `LIBZ_SYS_STATIC=1` • the `zlib-ng` features are enabled without `stock-zlib` Mitigations Fixed in `libz-sys@1.1.31`, which no longer logs the probe command. If you cannot upgrade, here are some workarounds: • Build with `LIBZ_SYS_STATIC=1` or the `static` feature, which skips the probe. • Pin `cc` to a release before 1.6.0 (`cargo update cc --precise <version>`). Note that upgrading `libz-sys` does not remove values already written. If an affected build already ran with secrets in its environment, clear CI caches and stored artifacts containing its target/build directory, and consider rotating those secrets.