rusty-shaper: 3x faster, lower-memory input-shaper calibration (Classic fallback retained)

[pdscomp]

rusty-shaper: 3x faster, lower-memory input-shaper calibration (Classic fallback retained)

Split from #252. Draft — commits not yet merged into this branch.

Why this PR

Classic input-shaper calibration is the largest single memory event on the CC1: Python Welch-PSD arrays scale with the full capture. This PR (a) bounds Classic's allocations, and (b) adds Rusty Shaper as the default implementation — same output, 68% faster, with UI and camera left running the whole time.

Justification / measurements (A/B on same flashed CC1; both selected MZV, X 55.4 Hz, Y 47.2 Hz)

Metric	Rusty	Classic	Rusty advantage
End-to-end time	70.2 s	221.2 s	151.0 s (68.3%)
Peak used RAM	76.58%	86.67%	10.09 pts
Min MemAvailable	26.82 MiB	15.26 MiB	11.56 MiB
Peak swap	21.25 MiB	55.75 MiB	34.50 MiB
Time with RAM ≥80%	0 s	8.8 s	avoids severe-pressure interval

Conservative result: Classic stops Grumpy/uStreamer during calibration; Rusty leaves both running and still wins.

Correctness gate: cargo test --locked replays 14 real community captures against Kalico-generated goldens (693cd75b); recommended shaper matches exactly, frequency within 0.5 Hz, per-shaper metrics within tolerances.

TBD: numbers re-measured on an image containing only this change set.

What changed

• 8450784: Kalico Welch PSD accumulates FFT energy in fixed 64-window batches; float32 captures; largest temporaries bounded by batch size, not capture length. Classic path stays available and gets safer.
• 8190d07: packages Rusty Shaper (GPL-3, checksummed Cargo deps), integrates into image/settings/macros. input_shaper = rusty default; classic is one setting away. Async worker — never blocks Klipper's reactor.

Risk / rollback

Low. Fallback is input_shaper = classic in settings — no reflash needed to revert behavior. Batch FFT patch is algorithmically identical (accumulation order only).

[pdscomp]

Feedback from @suchmememanyskill

• Doesn't disagree with swapping the shaper calculation engine — disagrees with how: a separate Rust process replaces an internal Kalico system, so every upstream Kalico change needs re-syncing; with Kalico's implementation he can trust it stays correct after updates.
• Suspects Classic's problem is "inefficient use of numpy" rather than needing a Rust rewrite; the batch FFT patch may already solve the real issue — Rusty may be redundant.
• Integration "works around kalico, breaking normal usage" — expects Rusty to hook into Kalico's shaper_calibrate internals, not replace the flow.
• Asks: what happens with SHAPER_CALIBRATE AXIS=X? Why two paths (standalone vs full-calibration)?
• Wants this area frozen: "Please don't make any changes in this area until I have put some thought and testing into it."
• General numpy note: Python can be efficient if numpy data is handed between functions as pointers — suspects several "Python slow" paths are fixable without rewrites.