perf(gif): decode a gif once across rayon workers

[LeadcodeDev]

Severity Medium, category quality. Location: crates/rustmotion-components/src/gif.rs:176

Impact

Triggering scenario: a scenario with one gif component, rendered to MP4. encode_with_ffmpeg (ffmpeg.rs:582) dispatches the FIRST chunk of batch_size = rayon::current_num_threads() * 2 frames — all frames 0..N of the same scene — to par_iter() at once. Every one of those workers calls Gif::paint_content, every one misses the still-empty gif_cache, and every one runs decode_composed_frames independently. Unlike icons and videos, GIFs are NOT preloaded (preload.rs only walks Component::Icon and Component::Video), so the first decode genuinely happens inside the parallel section. Each decode is itself unbounded: decode_composed_frames pushes one full-canvas RGBA copy per GIF frame with no cap (gif.rs:141). A 600-frame 800x600 GIF is 1.15 GB per decode; on a 16-core machine (batch_size 32) that is ~37 GB attempted concurrently, then 31 of the 32 results are thrown away when insert overwrites. The process OOM-kills before frame 33.

Fix

Decode GIFs in the preload pass alongside icons and videos (preload.rs), so the parallel section only ever hits a warm cache. If lazy decode must stay, gate it on a per-key single-flight primitive (e.g. DashMap<String, Arc<OnceLock<GifData>>> — insert the empty cell under the shard lock, then let exactly one worker fill it) and cap total decoded frames per source.

Evidence the audit read

let cached = if let Some(cached) = gcache.get(&self.src) {
    cached.clone()
} else {
    let Some(decoded) = decode_composed_frames(&self.src) else {
        return;
    };
    let cached = Arc::new(decoded);
    gcache.insert(self.src.clone(), cached.clone());
    cached
};
// decode_composed_frames, line 141:
frames.push((composed.clone(), canvas_w, canvas_h));

Based directly on the chantier branch.

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