encode.rs: seven mutants survive the whole test suite, three of them in compute_tqplus_calibration

[RyanCodrai]

Found while checking whether #457's mutation coverage was thin. It isn't #457's problem — encode.rs has zero diff on that branch, so the --in-diff gate would never surface these. They are pre-existing gaps.

Run: cargo mutants -p turbovec --file turbovec/src/encode.rs --file turbovec/src/rotation.rs --sharding round-robin --shard 0/6, using the same test set the mutants leg uses (--lib plus every integration test except io_v6). 116 mutants tested, 106 caught, 7 missed:

encode.rs:58:69    replace * with / in par_first_invalid_coord
encode.rs:100:26   replace < with == in first_invalid_in_chunk
encode.rs:564:14   replace >= with < in encode
encode.rs:723:71   replace + with * in compute_tqplus_calibration
encode.rs:749:45   replace < with > in compute_tqplus_calibration
encode.rs:809:28   replace > with >= in compute_tqplus_calibration
encode.rs:1181:5   replace fused_quantize_scale_pack -> f32 with 1.0

Three sit in compute_tqplus_calibration — the calibration fit itself, which is the code #454 corrected and which the per-block work in #457 depends on. A mutant surviving there means no test distinguishes the fitted parameters from subtly wrong ones.

encode.rs:1181 is the starkest: fused_quantize_scale_pack can return the constant 1.0 instead of a computed scale and nothing notices.

encode.rs:58 and :100 are in validation helpers, where a mutant surviving may mean the parallel path is only exercised on inputs where it agrees with the serial one.

Not urgent and not a blocker for anything in flight. Worth fixing because this is exactly the failure mode #367 documented — a test that passes on the broken code — and the calibration fit is a place where wrong-but-plausible parameters degrade recall silently rather than failing loudly.

Separately, three mutants in rotation.rs (+= → *= at apply_with_scratch:314, wht_block:578 and :618) exceed even 3x the baseline test time and land as TIMEOUT rather than MISSED. They reproduce with and without recall_sanity in the test set, so they are not an artifact of a slow suite. Whether they genuinely fail to terminate is worth a look on its own.

[RyanCodrai]

The encode-validation half is done (#528). The TQ+ half is not, and #529 — my attempt at it — is closed unmerged: the tests passed with the scale formula inverted and with the shift dropped entirely, and two of them passed against an uncalibrated index, so they were not coverage. Reasoning and measurements are on that PR.

Worth re-checking the premise before anyone retries. Four mutants I hand-wrote in compute_tqplus_calibration are all killed by the current suite — inverting the scale fails encode::anchor_tests::overload_does_not_worsen_with_more_bits. Those are not the three this issue names, so it proves nothing about them directly, but this issue's run used --lib plus a subset of integration tests, and I hit the same trap twice today: a restricted test set reports survivors that the full suite kills. A run over this function with the whole suite would establish whether the three are still live.

[RyanCodrai]

Re-ran this on today's main (2e4f4d8 + #532) with the same test set the mutants leg uses (--lib plus every integration test except io_v6 and recall_sanity), on aarch64. The issue's run was on x86 CI, and that difference turns out to matter.

15 mutants tested in 13m: 9 missed, 6 caught.

Line numbers have moved since c8d7ec02:

issue	today	verdict on aarch64
58:69 * with / in par_first_invalid_coord	67:69	caught
100:26 < with == in first_invalid_in_chunk	100:34 / 109:26	100:34 caught, 109:26 missed
564:14 >= with < in encode	606:14 (encode_prerotated)	missed
723:71 + with * in compute_tqplus_calibration	761:71	missed
749:45 < with >	787:45	missed — and < with == and < with <= at the same site miss too, so this is three surviving mutants, not one
809:28 > with >=	847:28	missed
1181:5 fused_quantize_scale_pack -> 1.0	1021 / 1219 / 1408	1021 (aarch64 body) caught; 1219 (x86 body) and 1408 (fallback body) missed

Two of the nine misses are not defects. fused_quantize_scale_pack has three cfg-gated bodies. On aarch64 the x86 one (1219) and the portable fallback (1408) are compiled out, so mutating them changes nothing and they survive vacuously — #421, not a missing test. The body that is live here, 1021, is caught. Symmetrically, whichever variant the x86 run flagged would have had the same problem in reverse.

Seven genuine survivors remain, at five sites:

• 109:26 — the tail-loop predicate in the aarch64 first_invalid_in_chunk. Note 100:34, the fallback scan inside the same function, is caught: the vector fast path is pinned, the scalar tail after it is not.
• 606:14 in encode_prerotated
• 761:71, 787:45 (×3), 847:28 in compute_tqplus_calibration

So the headline holds and is if anything understated: the calibration fit has five surviving mutants across three sites, not three, because 787:45 admits three different operator swaps that no test distinguishes. That is still the substance of this issue — nothing distinguishes correct calibration parameters from subtly wrong ones.

One methodological note for whoever picks this up: because two of the seven are arch-gated, a fix verified only on one architecture will leave the other's variant untested and the gate will keep reporting it. That part is #421.

Re-measured while closing out #531's decision-free fixes; no code changed.