fix: match MiniMax H3 keyframe preprocessing

[xledx]

Summary

Match MiniMax H3 first/last-frame preprocessing more closely with the reference implementation.

For FL2VA, the first keyframe is used as the geometry anchor and is resized to the target canvas, while the follower keyframe uses aspect-preserving cover resize + center crop.

Previously, the CLI resized/cropped both --init-img and --end-img before they reached the H3 pipeline, so the model-specific first/follower behavior could not be preserved.

This change:

• preserves the original MiniMax H3 keyframe images in the CLI before video generation
• keeps first-frame behavior unchanged in the H3 pipeline
• applies cover resize + centered crop only to the follower frame
• matches Python round() half-to-even behavior for resize geometry
• uses Lanczos interpolation with antialiasing for the follower resize
• does not change Ref2VA or other video models

I initially noticed a 1-pixel difference in MiniMax H3 follower-frame preprocessing. While tracing it, I found that the CLI was already center-cropping both keyframes before they reached the MiniMax H3 pipeline.

Related Issue / Discussion

None.

Additional Information

Validated on an Intel Mac, CPU-only.

• git diff --check passes
• sd-cli builds successfully
• resize/crop geometry matched the Python reference across tested source/target aspect ratios
• MiniMax H3 FL2VA smoke test completed successfully at 256x128, 5 frames, 1 sampling step
• both keyframes encoded successfully
• sampling and VAE decode completed successfully
• output video was written successfully
• decoded frame hashes differ from the previous preprocessing path for all 5 frames

The sd.cpp Lanczos implementation is not bit-identical to Pillow Lanczos, but antialias=true was substantially closer than antialias=false. The crop geometry itself matches the reference arithmetic.

Checklist

• I have read and confirmed this PR follows the contribution guidelines.