tests: delegate cargo_affected_stripped to the shared cargo_affected_with_env

[cargo-affected-bot]

Surfaced by the nightly survey of tests/functional/lib_bin_collision.rs.

cargo_affected_stripped is defined twice — in lib_bin_collision.rs and duplicate_target_names.rs — with byte-identical bodies, and both hand-roll the process spawn that cargo_affected_with_env in main.rs already provides. That helper exists for exactly this case; tests/CLAUDE.md lists it as the one "for scenarios that need to influence the build, e.g. RUSTFLAGS", and remapped_paths.rs uses it that way.

Each cargo_affected_stripped becomes a one-line delegation. The wrapper itself stays, because the name carries the scenario's intent (-C debuginfo=0) at every call site, and its doc comment is where each file explains why it strips debuginfo — a reason that differs between the two scenarios.

No behavior change: cargo_affected_with_env builds the same command from the same CARGO_BIN_EXE_cargo-affected path, sets the same env, and panics with the same message. Call sites and assertions are untouched, so no new test — the existing scenarios are the coverage, and CI exercises them (.github/workflows/ci.yaml installs llvm-tools and cargo-nextest before cargo test).

cargo fmt --check and cargo clippy --all-targets are clean, and the suite compiles. The two scenarios themselves can't run in the agent sandbox — they fail with cargo-affected requires cargo-nextest >= 0.9.116, the missing-tooling gap #96 addresses — so CI is what actually gates this one.

Deliberately kept off the doc-comment lines that #31 and #63 rewrite, so this should merge cleanly alongside either.