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

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.