ltx2: a corrupt checkpoint silently renders the synthetic rainbow gradient and reports success

[jamesbrink]

Summary

The LTX-2 native runtime keeps one last route that silently swaps a real render for the synthetic rainbow gradient: is_placeholder_checkpoint_error in crates/mold-inference/src/ltx2/runtime.rs. Any render failure whose message contains header too small, invalid header, or failed to parse safetensor is classified as a test placeholder checkpoint, so try_render_real_video returns Ok(None) and render_native_video falls through to fill_background.

Those are not test-only strings. candle re-exports the safetensors error with #[error(transparent)], and safetensors 0.7.0 renders SafeTensorError::HeaderTooSmall as literally header too small:

// safetensors-0.7.0/src/tensor.rs
HeaderTooLarge => write!(f, "header too large"),
HeaderTooSmall => write!(f, "header too small"),
InvalidHeaderLength => write!(f, "invalid header length"),

load_fp8_safetensors_with_callback propagates it with no added context (weight_loader.rs:193), so a truncated or interrupted checkpoint download reaches the classifier as exactly the text it matches on.

Impact

The user gets a video file with the requested resolution, length and frame rate, containing a smooth colour sweep and no scene, reported as ✓ Saved. This is the same user-visible failure as #665 — a plausible file that contains no picture — and it additionally hides the disk corruption that caused it. Diagnosing it requires MOLD_LTX_DEBUG=1, and even then the fallback logged only under a debug flag.

This also contradicts the contract the changelog states for #666: "only a missing checkpoint still falls back."

Reproduction

A unit test drives it directly — a present-but-truncated checkpoint currently renders placeholder frames and returns Ok:

test ltx2::runtime::tests::corrupt_checkpoint_fails_loudly_instead_of_rendering_the_synthetic_gradient ... FAILED

Expected

A checkpoint that is present but unreadable is corrupt real weights, not a test placeholder. The render must fail, and the error must name the offending checkpoint so the user can re-pull it. Only a genuinely missing checkpoint should keep the placeholder path, which is what the unit tests rely on.

Not this bug

The originally reported case — ltx-2-19b-distilled:fp8, two camera-control LoRAs, img2img --strength 0.60 — no longer reproduces on main. That was the LoRA gate in supports_real_video_path, fixed by #662 and #666. Verified on current main with real GPU renders; the specific two-LoRA + source-image combination was previously untested and is now covered by regression tests.