cargo clippy -D warnings and cargo fmt --check are red on the crate baseline

[d-laub]

cargo clippy --all-targets -- -D warnings and cargo fmt --check are both red on the crate today, independently of any in-flight work. This makes them unusable as CI or per-task gates: an implementer cannot tell their own regression from the ~100 diagnostics already there, so the gate gets waived, and a genuinely new lint then ships unnoticed.

Measured on the streaming line (commit bfa8e882, worktree trackb-record-mixed):

• cargo clippy --all-targets --message-format short → 11 hard errors, 89 warnings (50 duplicates)
• cargo clippy --message-format short (lib only) → 50 warnings
• cargo fmt --check → hunks across several files, including 8 in src/record_stream/engine.rs

Where the hard errors are

File	Lint
src/record_stream/transpose.rs (test module, ~:212-284)	erasing_op — "this operation will always return zero", from 0 * 2 * 2 style index arithmetic written out for readability in test fixtures
src/tracks/mod.rs:1278-1280, :2418, :2428	approx_constant — a literal approximation of π

The transpose.rs ones are arguably false positives worth an #[allow] with a comment: the expressions are spelled out as sample * ploidy * n + hap * n precisely so the indexing scheme is legible, and collapsing them to the constant clippy suggests would destroy that. The approx_constant ones should just use std::f64::consts::PI / f32::consts::PI.

The dominant warning class

clippy::type_complexity on PyO3 methods returning multi-element tuples of Bound<'py, PyArray1<T>>. In src/record_stream/engine.rs alone it fires at :607, :846, :866, :1019, :1075; also src/variants/mod.rs:360. A single type alias per return shape (or a small #[pyclass] struct where the tuple is genuinely a record) would clear all of them and improve the signatures. Others: single_range_in_vec_init across src/svar2/mod.rs, too_many_arguments on three src/tracks/mod.rs kernels, byte_char_slices, and a few doc-list indentation nits.

Suggested sequencing

1. cargo fmt the tree in one mechanical, review-free commit.
2. Fix the 11 hard errors (π constants; #[allow(clippy::erasing_op)] with a comment on the test index arithmetic).
3. Introduce type aliases for the PyO3 tuple returns, clearing type_complexity.
4. Sweep the remaining warning classes.
5. Only then add cargo fmt --check + cargo clippy --all-targets -- -D warnings to CI, so the gate stays green from the moment it exists.

Steps 1-2 are the cheap, high-value part and stand on their own.

Why now

Surfaced while reviewing #375 Track B, which added one PyO3 method to src/record_stream/engine.rs. Its task brief listed both commands as gates; neither could pass, and the new method contributes exactly one type_complexity warning — a lint already firing on four sibling methods in the same file. Suppressing it on the new method alone would have made it inconsistent with its neighbours, so the debt is being tracked here instead of patched piecemeal.

Not streaming-board work: the debt spans tracks/, svar2/, and variants/ as well as record_stream/.