[Bug] PR #15486 `v = v.clone()` in H3 Attention causes ~1.1 GB VRAM regression on 16 GB GPUs -> WDDM spill / multi-x slowdown

## Description

After PR #15486 ("Fix peak memory issue with H3", commit `62b3c94b`), H3 long-video generation on a 16 GB GPU regresses sharply: peak VRAM climbs from ~14.5 GB to ~15.6 GB, pushing utilization to ~97.5% of the 16 GB ceiling. Under Windows WDDM this overflows tensor allocations into system RAM over PCIe, slowing the entire sampling + VAE pipeline by several times.

The only change introduced by #15486 is a single line in `comfy/ldm/minimax/model.py`, inside `class Attention`:

```python
else:
q = self.q_norm(q.view(s, self.heads, self.head_dim))
k = self.k_norm(k.view(s, self.heads, self.head_dim))
+ v = v.clone()
q = AttentionTensorContainer(q.transpose(0, 1).unsqueeze(0))
k = AttentionTensorContainer(k.transpose(0, 1).unsqueeze(0))
v = AttentionTensorContainer(v.transpose(0, 1).unsqueeze(0))
```

Adding `v = v.clone()` allocates an extra copy of the (very large) value tensor. For H3 with long latent sequences this extra copy alone accounts for the ~1.1 GB jump in peak VRAM, which is enough to cross the 16 GB WDDM spill threshold on this card.

## Reproduction

- **Hardware:** NVIDIA RTX 5070 Ti, 16 GB VRAM; AMD Ryzen 7 9700X; Windows 11 24H2; driver 610.88 (WDDM).
- **Software:** ComfyUI `62b3c94b` and later (verified the line is still present at `bd34f338`); `comfy-aimdo==0.4.13` DynamicVRAM paging enabled.
- **Model:** MiniMax H3, text-to-video, 720p / 15 s / 24 fps.
- **Observed peak VRAM on this machine (git-bisected):**
- `fe4195f` (2026-08-08): ~14.5 GB - fastest / normal.
- `bf4c9a08`: ~14.5 GB - normal.
- `62b3c94b` (#15486): ~15.6 GB (~97.5% of 16 GB) -> WDDM spill -> sampling + VAE several times slower.
- `27bca654`, `26d7f85`, `bd34f338`: all still carry the `v = v.clone()` line; regression persists.

## Local workaround

Removing the `v = v.clone()` line restores `fe4195f` / `bf4c9a08`-level VRAM and speed on this 16 GB setup, with no apparent correctness regression in our H3 testing (no visual artifacts; outputs identical across several seeds).

## Ask

The clone was added to "fix a peak memory issue with H3", so it may be load-bearing for correctness or memory on other configurations. Could the maintainers please:

1. Confirm whether the clone is required for correctness (e.g. the value tensor is modified in-place elsewhere and must be detached), and
2. If it is only a memory optimization, consider guarding it behind a flag or making it conditional - on <=16 GB GPUs it causes a severe *opposite* regression.

Thanks!

Start in comfy/ldm/minimax/model.py at class Attention and inspect the v = v.clone() change from PR #15486. Reproduce H3 long-video generation using the supplied 16 GB Windows setup or compare the cited commits, then determine whether removing or conditioning the clone preserves correctness while avoiding the reported VRAM and WDDM slowdown.

Written by the indexing model from the issue text.