fix(encode): reject a non-positive playback rate

[LeadcodeDev]

Severity Medium, category correctness. Location: crates/rustmotion/src/encode/video_audio.rs:221

Impact

remaining never reaches 0.5 when it starts at 0.0 (0.0/0.5 == 0.0) or at any negative value (it diverges toward -inf). The loop never terminates and pushes a fresh String on every iteration, so rustmotion hangs while consuming memory until the OOM killer fires. Reached from a plain scenario JSON: {"type":"video","src":"clip.mp4","playback_rate":0} — volume defaults to 1.0 (crates/rustmotion-components/src/video.rs:14 fn default_volume() -> f32 { 1.0 }), so collect_videos_in_child collects it (v.volume > 0.0, line 128), collect_video_audio_tracks calls extract_audio_to_wav(..., occ.playback_rate) (line 421), which calls build_atempo_filter(0.0) at line 333. playback_rate is an unvalidated Option<f64> (crates/rustmotion-components/src/video.rs:26); a repo-wide grep shows no validator constrains it. Both the ffmpeg render path (encode_with_ffmpeg_hw_impl line 432) and the native path (mux.rs:34) reach it.

Fix

Guard the entry point: if !rate.is_finite() || rate <= 0.0 { return None; } (or surface a schema error naming the component), and additionally bound the stage count so no future arithmetic edge case can spin. A validation rule rejecting playback_rate <= 0 at load time would also stop preload.rs:182, which consumes the same field.

Evidence the audit read

} else {
        // Each stage multiplies by at least 0.5
        while remaining < 0.5 - EPSILON {
            parts.push("atempo=0.5".to_string());
            remaining /= 0.5;
        }

Stacked on fix/encode-atomic-output, which carries the previous finding of this workstream. GitHub shows only this finding's diff; merge in order.

Part of the September 2026 audit remediation chantier. Refs #220 (RM-18).