M4 Pro 24GB verification: official sharded weights render cleanly; misaligned repacked weights produce garbage (confirms PR #14)

**Device:** Mac mini M4 Pro, 24 GB unified memory, macOS 26.6.1
**Build:** commit 8974cc0, `--ssd-streaming` (BF16 DiT layers streamed from SSD)

Sharing M4 Pro (24GB) results with the **official MiniMaxAI/MiniMax-H3 sharded weights**, to complement the existing M4 Max (64GB) data in #5.

## Timing (full pipeline, includes text encoder + VAE + FFmpeg)

| Canvas | Frames | Steps | Total time |
|---|---|---|---|
| 256×256 | 22 | 20 | 3m46s |
| 512×512 | 22 | 20 | 4m29s |
| 832×480 | 124 | 20 | 44m46s |

Prompt: official README example ("A red fox walks through fresh snow in a pine forest."), layers 50, reuse 1, default seed.

## Root-cause confirmation for the noise issue

Previously, with the Comfy-Org repackaged single-file weights (safetensors with misaligned data segments — our text_encoder data offset %8 = 5, video_vae %8 = 7), **every render came out as uniform texture noise** (T2VA and FL2VA alike, both warm-up and full runs).

After switching to the official MiniMaxAI/MiniMax-H3 shards (13-piece transformer + 14-piece text encoder + official F32 video VAE, no conversion, no repacking), renders are **completely clean** — proper detail, no artifacts, verified at both 256 and 512 canvases.

This is a practical confirmation that the misalignment issue described in PR #14 is real: unaligned repacked weights silently decode to garbage on the GPU path, while official weights work as-is.

For reference: 1344×768 / 124 frames / 6 steps was ~71.5 min total with the old (repacked) weights.

Happy to provide more data (e.g., first/last frame conditioning timings at 832×480) if useful.