MiniMax H3: plain bf16 checkpoints (full and pruned) sample to 100% black frames on v0.32.0; int8_convrot repacks of the same weights work

## Summary

Both plain-bf16 MiniMax H3 Ref2VA checkpoints from `Comfy-Org/MiniMax-H3`
(`minimax_h3_ref2va_bf16.safetensors`, 61.7 GB, and
`minimax_h3_ref2va_pruned_bf16.safetensors`, 37.5 GB) sample to fully black
video (every pixel 0, all frames) on ComfyUI v0.32.0, while the
`*_int8_convrot` repacks of the same weights run correctly on the identical
graph, seed, and server. Evidence below isolates the failure to the
non-quantized H3 inference path, not the files, attention backend, VAE
precision, or VRAM pressure.

## Environment

- ComfyUI v0.32.0 (commit 27bca654, 2026-08-12), Windows 11, python 3.12
- torch 2.12.0+cu130, RTX PRO 6000 Blackwell 96 GB (sm_120), driver 596.86
- Launch flags: `--disable-dynamic-vram` (comfy-aimdo streaming loader crashes
on quantized tensors on this card - separate issue), sage attention 2.2.0
(also reproduced with sage disabled)

## Reproduction

Core-node Ref2VA graph (UNETLoader -> CLIPLoader(minimax) -> MiniMaxH3ReferenceToVideo
-> MiniMaxH3SigmaShift(12/3) -> KSampler(res_multistep/simple, 21 steps, cfg 4)
-> LTXVSeparateAVLatent -> VAEDecode), 1344x768, 192 frames.

- DiT = `minimax_h3_ref2va_int8_convrot.safetensors` -> correct video
- DiT = `minimax_h3_ref2va_bf16.safetensors` -> 100% black, every frame
- DiT = `minimax_h3_ref2va_pruned_bf16.safetensors` -> 100% black, every frame

TE = `qwen3vl_32b_minimax_h3_bf16.safetensors` in all runs (unchanged).

## What has been ruled out

| Hypothesis | Result |
|---|---|
| Corrupt download | SHA256 of both bf16 files matches the HF LFS oid exactly |
| sage attention | Reproduced with sage removed (pytorch attention) - still black |
| fp16 video VAE clamp | Reproduced with `--fp32-vae` - still black (so the latents are already dead before decode) |
| Repack weight error | Tensors stored in fp in BOTH files (audio_patch_proj.weight/.bias, adaln biases) are bit-identical between the bf16 and int8_convrot files |
| Architecture variant mismatch | Both files use the time_embedder layout (no adaln_t_table); key sets consistent |
| Metadata `config` override in model_detection | All 20 transformer config values equal the shape-derived values; extra keys are absorbed by `**kwargs` in the H3 constructor |
| VRAM pressure | Full model peaked at 81.5/97.9 GB (no OOM, normal step speed); pruned bf16 ran with ~60 GB VRAM free on a freshly restarted server - still black |

## Remaining suspect

With detection, initialization, files, attention, VAE and memory excluded, the
only path that differs between the working and failing runs is runtime op
dispatch: int8_convrot layers execute through the comfy_kitchen quantized
kernels, while plain bf16 layers execute through standard ops. The plain
(non-quantized) H3 weight path appears to be broken/unvalidated - latents come
out of sampling already dead (black survives fp32 decode).

Supporting observation (tensor-header verified): applying the 4-step Turbo
LoRA to the FULL int8_convrot DiT also produces all-black frames on the first
step (video_rms=nan), while the same LoRA on the pruned int8 model works. The
LoRA is the original full-model form and carries AdaLN adapters with effective
delta shape [96768, 2688]:

- pruned model: `adaln_proj.linear.weight` is [96768, 64] plain F32
(curve-form) -> shape mismatch -> the AdaLN adapters are silently skipped,
only attn/mlp adapters apply -> run works.
- full model: `adaln_proj.linear.weight` is [96768, 2688] INT8 + weight_scale
-> shapes match -> the AdaLN LoRA actually patches the quantized layer.
Merging a LoRA into a comfy_quant int8 tensor requires dequantizing it to a
plain weight - which lands on the same suspect plain-weight execution path.

So all three black-frame cases observed here (full bf16, pruned bf16,
full int8 + Turbo LoRA) are consistent with a single root cause: the
non-quantized H3 weight path.

## Ask

Can anyone reproduce plain-bf16 H3 sampling producing valid (non-black) video
on v0.32.0? If the plain path is currently out of scope, a load-time warning
("this checkpoint requires the comfy_quant repack") would save users a 60 GB
download.

Reproduce the listed Ref2VA graph with the plain-bf16 and int8_convrot MiniMax H3 checkpoints, comparing whether latents are already black before VAE decode. Then inspect the H3 constructor, model_detection, and the differing runtime op dispatch paths; done means valid non-black sampling or a justified load-time warning for unsupported plain checkpoints.

Written by the indexing model from the issue text.