Krea2 long prompts exceed reference 512-token conditioning limit and produce corrupted outputs

### Custom Node Testing

- [x] I have tried disabling custom nodes and the issue persists (see [how to disable custom nodes](https://docs.comfy.org/troubleshooting/custom-node-issues#step-1%3A-test-with-all-custom-nodes-disabled) if you need help)

### Expected Behavior

Krea2 should handle long prompts consistently with the official Krea 2 reference inference implementation, or explicitly truncate the text conditioning to the model's supported reference sequence length.

A long prompt should not silently produce a black or corrupted/noisy image while the sampler and VAE complete successfully without an exception.

### Actual Behavior

Long prompts can produce deterministic black or corrupted/noisy outputs with Krea2.

The workflow completes normally:

• KSampler reaches 8/8 steps
• no Python exception is raised
• no OOM occurs
• VAE decoding completes
• the final image is black or visually corrupted

I traced the Krea2 text-conditioning sequence length and found a strong correlation with the final conditioning sequence length.

Test results using the same long prompt, workflow, model, and generation settings:

Final Krea2 conditioning sequence | Result
-- | --
49 | OK
512 | OK
513 | OK
576 | OK
640 | Black output
674 | Corrupted/noisy output

The original long prompt produces:

raw_chars=3785

token_pairs=708

template_end=34

final conditioning seq=674

conditioning shape=(1, 674, 30720)

The original ComfyUI Krea2 path therefore passes all 674 post-prefix conditioning positions to the Krea2 model.

I compared this with the official Krea 2 reference encoder. The reference implementation uses a default max_length=512 and truncates the prompt body while preserving the final 5-token template suffix.

I implemented a local diagnostic workaround that performs this truncation before Qwen3-VL text encoding.

With the same 3785-character prompt:

[KREA2-TRACE] stage=TOKENIZE batch=0 raw_chars=3785 before_tokens=708 after_tokens=546 template_end=34 seq_limit=512 truncated=True

[KREA2-TRACE] stage=PRE_STRIP token_pairs=546 out_shape=(1, 12, 546, 2560) template_end=34

[KREA2-TRACE] stage=POST_STRIP seq=512 tap_count=12 hidden=2560 seq_limit=512 over_limit=False

[KREA2-TRACE] stage=FINAL conditioning_shape=(1, 512, 30720) final_mask_shape=None

The image then generates normally.

This appears to be related to a difference between the ComfyUI Krea2 text encoder path and the official Krea 2 reference inference path.

### Steps to Reproduce

Run the latest ComfyUI with all custom nodes disabled.
Load the official Comfy-Org Krea2 INT8 ConvRot checkpoint.
Use the official/basic Krea2 text-to-image workflow.
Use a sufficiently long prompt. My reproducible prompt produces 708 Qwen3-VL token pairs and 674 final Krea2 conditioning positions after the 34-token template prefix is stripped.
Generate the image.

Observed result:

final_seq=674

The sampler completes normally, but the generated image is corrupted/noisy.

I also tested controlled conditioning sequence limits using the exact same prompt and workflow:

512 -> OK
513 -> OK
576 -> OK
640 -> black image
674 -> corrupted/noisy image

The sequence length was the only intentionally changed variable.

A local workaround that truncates the token sequence before Qwen3-VL encoding, preserving the final 5 template suffix tokens and producing a final 512-position conditioning tensor, restores normal generation.

### Debug Logs

```powershell
Environment:

Platform: Linux
Python: 3.13.12
PyTorch: 2.11.0+xpu
Device: Intel(R) Arc(TM) Pro B60 Graphics
ComfyUI: 0.27.0 / development master
comfy-kitchen: 0.2.16
Triton: 3.7.0

Relevant original model loading path:

Found quantization metadata version 1
Detected mixed precision quantization
Using mixed precision operations
Native ops: int8_tensorwise
model weight dtype torch.bfloat16, manual cast: torch.bfloat16
model_type FLUX
Requested to load Krea2

Relevant diagnostic trace without truncation:

[KREA2-TRACE] stage=TOKENIZE raw_chars=3785 token_pairs=708
[KREA2-TRACE] stage=PRE_STRIP token_pairs=708 out_shape=(1, 12, 708, 2560) mask_shape=(1, 708)
[KREA2-TRACE] stage=POST_STRIP template_end=34 seq=674 tap_count=12 hidden=2560 over_512=True
[KREA2-TRACE] stage=FINAL conditioning_shape=(1, 674, 30720) final_mask_shape=None

Relevant diagnostic trace with pre-encoder reference-style truncation:

[KREA2-TRACE] stage=TOKENIZE batch=0 raw_chars=3785 before_tokens=708 after_tokens=546 template_end=34 seq_limit=512 truncated=True
[KREA2-TRACE] stage=PRE_STRIP token_pairs=546 out_shape=(1, 12, 546, 2560) template_end=34
[KREA2-TRACE] stage=POST_STRIP seq=512 tap_count=12 hidden=2560 seq_limit=512 over_limit=False
[KREA2-TRACE] stage=FINAL conditioning_shape=(1, 512, 30720) final_mask_shape=None
```

### Other

The official Krea 2 reference encoder appears to use a default text conditioning maximum length of 512 and performs prompt-body truncation before text encoder inference while preserving the final template suffix.

In the current ComfyUI implementation, Krea2 inherits the Qwen3-VL tokenizer path and the resulting conditioning sequence is not capped to the Krea reference length before being passed to Krea2.

I am not certain whether the correct upstream fix is:

restoring a Krea2-specific 512 sequence limit in Krea2Tokenizer,
making the Qwen3-VL tokenizer max length model-configurable,
or fixing support for Krea2 conditioning sequences above the reference length.

I have a working local patch that performs reference-style pre-encoder truncation and can prepare a PR if this is the intended fix direction.

Possibly related to #14717, although that report does not currently identify prompt/conditioning sequence length as the trigger.

Start by tracing the Krea2Tokenizer and Qwen3-VL tokenizer path mentioned in the issue, then compare its sequence handling with the official Krea 2 reference encoder's max_length=512 behavior. Reproduce the reported 674-position conditioning case and verify the chosen fix preserves the template suffix, caps the final conditioning sequence appropriately, and restores normal image generation.

Written by the indexing model from the issue text.