fix(gif): cap decoded gif dimensions and frame count

[LeadcodeDev]

Severity Medium, category security. Location: crates/rustmotion-components/src/gif.rs:129

Impact

decoder.width()/height() come straight from the GIF logical-screen descriptor (2 bytes each, max 65535). A ~200-byte crafted GIF declaring 65535×65535 makes line 129 request a single 17.2 GB allocation before a single pixel is decoded. Worse, the while loop then pushes a full-canvas clone per animation frame (line 141) with no frame-count limit — a 4000×4000 canvas with 500 frames is 32 TB of Vec<u8> — and the result is inserted into the global gif_cache() (renderer/assets.rs:32) which is never evicted. A scenario whose gif src points at such a file aborts the render process (Rust allocation failure = abort, not a catchable error), which is a denial of service on any batch/CI renderer fed third-party scenarios or media.

Fix

Before allocating, reject canvases above a configured budget: check canvas_w as u64 * canvas_h as u64 * 4 against a cap (and compare against the video's own dimensions — nothing larger can be usefully drawn) and return None with a warning, exactly like the existing decode-failure arms. Add a frame-count cap to the while loop, and prefer storing only the deltas or re-decoding on demand rather than cloning the whole canvas per frame.

Evidence the audit read

let canvas_w = decoder.width() as u32;
    let canvas_h = decoder.height() as u32;

    let mut frames: Vec<(Vec<u8>, u32, u32)> = Vec::new();
    let mut cumulative_times: Vec<f64> = Vec::new();
    let mut accumulated = 0.0;
    let mut composed = vec![0u8; canvas_w as usize * canvas_h as usize * 4];

    while let Ok(Some(frame)) = decoder.read_next_frame() {
        ...
        frames.push((composed.clone(), canvas_w, canvas_h));

Stacked on perf/video-frame-cache-budget, 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-23).