smart-memory / dynamic-vram causes: Krea 2 gives inconsistent results (same seed/WF) when bypassing loras or zero value lora. WF to reproduce included.

### 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

running a workflow twice with fixed seed should give same result.
bypassing a lora turned off or at weight 0 should have no impact.

### Actual Behavior

**[EDIT: found smart-memory or dynamic-vram is responsible - see later!]**

Really odd behaviour with inconsistent result from same workflow in Krea

No custom nodes!

I first spotted problem when i had 3 rgthree 'power lora loader' nodes in series. all loras turned OFF, yet, bypassing a (turned off) node made a subtle difference to output!
Sequence of bypassing then re-enabling nodes actually changed result - so that loading a workflow by dragging an image just created back into ComfyUI sometimes gave a subtly different output when run again.

I investigated with NOT using custom nodes: same bug!

I tried putting 3 'LoadLoRA' nodes in series. Despite lora weight being set to '0', if i bypass a node with weight '0' the output is effected!

### Steps to Reproduce

Simplest way to replicate bug:

[krea2_turbo_t2i_problem_using_loadLOrA_a.json](https://github.com/user-attachments/files/29514348/krea2_turbo_t2i_problem_using_loadLOrA_a.json)

- start with --disable-all-custom-nodes
- Load provided V simple workflow.
- run workflow (to get image 1)
- bypass the last lora node
- run again (to get image 2)

Result: 2 slightly different pictures.

Freaky behaviour goes on.. next try:

- restart ComfyUI
- drag your 'image 2' to canvas to get the workflow
- run it again

Result: you get the same image as 'image 1' - i.e. the non-bypassed node.

Now try with power lora loader, if you feel a lora at weight '0' is not the same as a bypassed lora:

[krea2_turbo_t2i_problem_using_RGthree_PowerLoraLoader_a.json](https://github.com/user-attachments/files/29514470/krea2_turbo_t2i_problem_using_RGthree_PowerLoraLoader_a.json)

- start with ComfyUI (you need rgthree's node pack, obviously)
- Load provided V simple workflow.
- run workflow (to get image 1)
- bypass the last lora node (they're all turned off!)
- run again (to get image 2)

You'll have to update model / clip / VAI / lora links to your exact locations, obviously. You can test with any LoRAs you want. I just used standard offerings to make it easier to reproduce.

Note, tried same test changing model/clip/vae to z-image. That isn't effected by this behaviour; results consistent.

### Debug Logs

```powershell
ComfyUI 0.26.2
aimdo: 0.4.10
Front-end: 1.45.19
kitchen: 0.2.10
pytorch 2.9.1 / cu130 on a 5090.

I can provide actual terminal log if you can't reproduce this (just ask), but there's no clues in it. Just try the workflows I've provided.
```

### Other

_No response_

Start by reproducing the behavior with --disable-all-custom-nodes using krea2_turbo_t2i_problem_using_loadLOrA_a.json, then compare runs before and after bypassing the final LoadLoRA node. Check the issue's later finding that smart-memory or dynamic-vram is responsible, and compare against the z-image test. Done means fixed-seed runs remain identical when a LoRA is bypassed or has weight 0.

Written by the indexing model from the issue text.