[Windows][RTX 3080] Krea 2 INT8 ConvRot hard-reboots PC at KSampler start; Q8 GGUF is stable

### Custom Node Testing

- [ ] I have tried disabling custom nodes and the issue persists.

I have not yet done a `--disable-all-custom-nodes` reproduction because the failure is a full system reboot rather than a recoverable ComfyUI/Python crash. I can test this if requested.

### Expected Behavior

The official Krea 2 INT8 ConvRot checkpoint should begin sampling normally on an RTX 3080, or fail with a recoverable CUDA/Python error. It should not black-screen the GPU and reboot Windows.

### Actual Behavior

Using the official `krea2_turbo_int8_convrot.safetensors`, the machine now hard-reboots as soon as execution reaches KSampler / the first model forward pass.

Observed sequence:

1. Screen goes black immediately when KSampler starts.
2. The machine automatically restarts and goes straight through POST/bootloader.
3. There is no visible BSOD.
4. Windows `Kernel-Power 41` reports:

```text
BugcheckCode: 0
BugcheckParameter1: 0x0
BugcheckParameter2: 0x0
BugcheckParameter3: 0x0
BugcheckParameter4: 0x0
```

There is therefore no normal Windows bugcheck recorded for the crash.

The GPU is not at full utilization when the failure occurs; it happens at model initialization / the beginning of sampling rather than mid-generation.

### Important history / state sensitivity

This has behaved in a state-sensitive way:

- On a previous ComfyUI installation, this Krea 2 INT8 ConvRot model had already caused the same kind of hard reboot.
- I then made a fresh ComfyUI installation. The exact same INT8 checkpoint started working correctly again.
- It generated successfully multiple times, including with a combination of LoRAs.
- I disabled one LoRA and enabled a different LoRA.
- On the next run, the machine hard-rebooted immediately when KSampler started.
- After that first crash, the INT8 checkpoint began hard-rebooting even with **no LoRA enabled**.
- Rebooting Windows does not restore stability.

I am not claiming the LoRA is the root cause. It may simply have forced a model repatch/reload/re-staging path that exposed the failure.

### Control test: Q8 GGUF is stable

The same Krea 2 workflow using a Q8 GGUF model does **not** crash the system.

So far the clean split is:

```text
Krea 2 INT8 ConvRot -> hard reboot at KSampler start
Krea 2 Q8 GGUF -> stable
```

This is why I suspect the official INT8 ConvRot / comfy-kitchen / model streaming path rather than general GPU load.

### Power-limit test

I lowered the RTX 3080 power limit to 70% in MSI Afterburner and reproduced the same hard reboot.

This did not change the failure behavior.

### Model integrity

The checkpoint hash matches the official Comfy-Org Krea 2 Turbo INT8 ConvRot file exactly:

```text
File: krea2_turbo_int8_convrot.safetensors
SHA256: 8e4eeda70dd5037ab1ba2bef6b417f9f901e26093117cf397f741fc1fdaaf3f1
```

### Environment

```text
OS: Windows 11
GPU: NVIDIA GeForce RTX 3080 10 GB
Driver: 610.62
CUDA UMD reported by nvidia-smi: 13.3
PyTorch: 2.13.0+cu130
ComfyUI commit: 12666983
comfy-kitchen: 0.2.31
comfy-aimdo: 0.4.13
comfyui-manager: 4.2.2
NumPy: 2.5.2
Triton: not installed
```

`pip check` reports:

```text
No broken requirements found.
```

### comfy-kitchen backend state

`comfy_kitchen.list_backends()` shows:

```text
cuda: available=True, disabled=False
includes int8_linear, quantize_int8_convrot_weight,
dequantize_int8_convrot_weight, rotate_int8_convrot_weight, etc.

eager: available=True, disabled=False

triton: available=False
ImportError: No module named 'triton'
```

So the normal CUDA backend is enabled.

### Steps to Reproduce

Current state on my machine:

1. Start current ComfyUI normally.
2. Load the official Krea 2 Turbo INT8 ConvRot checkpoint.
3. Use a normal Krea 2 text-to-image workflow.
4. No LoRA is required now.
5. Queue the prompt.
6. Model/text encoder loading proceeds.
7. As soon as KSampler begins / the diffusion model starts its first forward pass, the display goes black and Windows automatically reboots.

The crash is currently reproducible without the LoRA that originally appeared to trigger it.

### Debug logs

There is no Python traceback from the failing run because the entire machine resets before ComfyUI can log an exception.

Relevant environment output:

```text
comfy-kitchen 0.2.31
torch 2.13.0+cu130
CUDA 13.0 (PyTorch build)
RTX 3080 10 GB
NVIDIA driver 610.62
```

`nvidia-smi`:

```text
NVIDIA-SMI 610.62
KMD Version: 610.62
CUDA UMD Version: 13.3
GPU: NVIDIA GeForce RTX 3080
Driver model: WDDM
```

### Related issues

Possibly related, but not identical:

- #14719 - RTX 3080 Ti system freeze with comfy-kitchen CUDA backend
- #15255 - DynamicVRAM / HostBuffer failures on Windows, including Krea 2
- #15488 - quantized comfy-kitchen workload causing GPU loss / TDR black screen
- #14658 - Krea 2 crash at the first KSampler step on ROCm (different backend/platform)
- #14714 - CUDA illegal-memory-access / black-screen regression on Windows with another model

### Other

The main oddity is that the same fresh installation worked correctly for a while, then the first hard reboot happened immediately after changing the active LoRA, and after that the INT8 checkpoint began crashing even with no LoRA.

The Q8 version remaining stable on the same GPU/workflow makes this look specific to the INT8 ConvRot execution path rather than a generic inability of the GPU to run Krea 2.

I would prefer to keep using the official/default INT8 ConvRot CUDA implementation because it is substantially faster than Q8 on this RTX 3080. I can run additional targeted diagnostics if there are specific flags/logging builds that would help isolate the failing kernel or model-loading path.

Start by reproducing the failure with the official krea2_turbo_int8_convrot.safetensors workflow at KSampler startup, then compare it with the stable Q8 GGUF path. Inspect the comfy-kitchen CUDA backend and its listed INT8 ConvRot operations, using the related issues as context. Done means isolating the failing execution path or producing a reproducible diagnostic that prevents the hard reboot.

Written by the indexing model from the issue text.