Performance: 1344x768 / 5s renders wait-dominated (GPU idle per profile) on M5 Max — measured dataset

### Summary
At 1344×768 / 124 frames (5.17s), the DiT denoise is extremely slow on M5 Max even with healthy memory: ~36 min wall for 20 steps, and the profile shows `wait ≈ wall` with tiny `root-gpu`. The documented >3,072-row MPSGraph fallback is the likely cause, but there are no published timings for production shapes (5s+, widescreen) to confirm whether this is expected. This report adds measured numbers so the cost model is explicit.

### Environment
- MacBook Pro, Apple M5 Max, 128 GB unified, macOS 26.5.2, Metal 4
- h3.c @ 8974cc0 (`--ssd-streaming` included), default int8 path on M5
- Model: official HF snapshot `MiniMax-H3` (FL2VA)
- Command: `./h3 --profile -d ./MiniMax-H3 -p "" --seed 42 --width 1344 --height 768 --frames 124 --steps 20 --layers 50 --reuse 1 --ssd-streaming`
- `H3_VAE_TILE_PIXELS=256`

### Measured `--profile` (GPU Euler denoise)
| Config | rows* | denoise wall | root-gpu | encode | wait |
|---|---:|---:|---:|---:|---:|
| 1344×768, 124f | 37,296 | 2176.1s | 3.8s | 0.61s | 2175.4s |
| 896×512→out 1344, 124f | 16,576 | 1028.1s | 2.5s | 0.56s | 1027.5s |
| 672×384→out 1344, 124f | 9,324 | 372.8s | 1.2s | 0.53s | 372.2s |
| 1344×768, 22f | 7,056 | 223.1s | 0.8s | 0.51s | 222.5s |
| 512×512, 22f | 1,792 | 19.5s | 19.4s | — | ~0 |

\* rows = `latent_t × (W/32) × (H/32)`, latent_t(124f)=37, latent_t(22f)=7 (h3_host.c).

`H3_PROFILE=1` on the 1344×768/22f case: `command_encode` tiny (~0.5s), so the CPU is not stuck encoding; the wait appears to be MPSGraph child-buffer execution that `root-gpu` can't see. GPU busy via powermetrics not collected (needs root).

`H3_NAX=1` on 1344×768/22f: 265.8s vs 223.1s baseline (no improvement — consistent with NAX kernels never selected >3,072 rows).

### Observations
- 512×512/22f (1,792 rows) is healthy: root-gpu ≈ wall.
- At ≥ 4,352 rows (512² @ 56f = 2.33s) everything is wait-dominated.
- SSD streaming fixed memory (DiT peak ~2.6–3.7 GiB, RAM stable) but did not help speed — as documented, it's a memory/speed tradeoff.
- Internal render downscale (672×384 / 896×512 → upscaled 1344×768 output) is the only practical way to cut time, at a visible quality cost; no internal canvas at 124f gets under 3,072 rows in a valid 1.75:1 aspect.

### Questions
1. Is this wait-dominated profile at >3,072 rows expected/accepted today, or a known optimization gap (e.g. NAX TensorOps >3,072-row split, MPSGraph scheduling for production shapes)?
2. Any recommended env/flags for production 5s+ widescreen before the large-sequence path is optimized (e.g. `H3_GPU_SAMPLER_WINDOW`, command blocks, NAX variants)?
3. Would a contributed benchmark (this table, exact cmd + profile output) be useful in the README to set expectations for 4–15s widescreen renders?

Happy to share full `--profile` logs or the exact test prompt if useful. Thanks for the great project.