Unverified: .cargo/config.toml forces target-cpu=x86-64-v2 in-repo but not for downstream builds

Split out of #346, which #438 closes. #346's title and Fix: section were about the statrs caret range; both halves of that are now resolved (the golden pin landed earlier on main, the exact-pin in #438). This is the "PLAUSIBLE, related" note at the bottom of that issue, which #438 deliberately did not touch — recording it so the close does not bury it.

The concern

.cargo/config.toml:22-23 forces -C target-cpu=x86-64-v2 for in-repo x86_64 builds. That file is not published with the crate, so a downstream user compiling turbovec gets the default target CPU instead.

The worry #346 raises is that in-repo testing and downstream compilation therefore differ in instruction selection, and that this could in principle affect floating-point results — which, given statrs' inverse_cdf feeds TQ+ calibration and hence encoded bytes (see turbovec/src/encode.rs:667-672), would be the same class of silent-byte-change #346 was about.

Status: unverified

#346 labels this PLAUSIBLE and self-assesses the risk as low. Nobody has established whether it is real. The question worth answering:

• Does -C target-cpu=x86-64-v2 versus the default actually change any value on the encode path? The likely mechanism is FMA contraction or vectorised reductions altering rounding. Note the crate already has explicit runtime SIMD dispatch and an avx2 && fma check, so the interesting case is whether the scalar/portable paths shift.
• The encode fingerprint machinery can answer this directly: build the fingerprint with and without the flag on the same x86 host and compare. turbovec/tests/encode_fingerprint.rs pins absolute hashes, and there is already a cross-OS agreement leg, so the comparison is cheap to run.
• If the answer is "no difference", the right outcome is a comment in .cargo/config.toml recording that it was checked and why it is safe. If the answer is "difference", it is a genuine reproducibility bug and the flag should go, or the published crate should pin the same baseline.

An x86 host is required; this cannot be settled on arm64.

Provenance

The "PLAUSIBLE, related" paragraph of #346, confirmed still open during the round-1 review of #438.