Node bodies stop rendering after VRAM-heavy run; links still paint; reload does not recover (external browser unaffected)

## Summary

After a run that transiently exhausts VRAM, node bodies stop rendering entirely in the Desktop app window, while link splines continue to paint normally. The canvas becomes extremely slow. `Ctrl+R` / F5 / the title-bar refresh do not recover it — only a full quit and relaunch does.

**The same workflow, same backend, same session, same VRAM pressure renders perfectly in an external browser pointed at `127.0.0.1:8188`.** Frontend and backend are identical in both cases; only the Electron renderer fails. That is why this is filed here rather than against ComfyUI_frontend.

Because nodes are Vue DOM elements composited on the GPU and links are painted on the 2D canvas, the failure is visually unambiguous: an empty grid with wires floating on it.

## Environment

- ComfyUI Desktop 1.0.34 (AppImage, `--no-sandbox`)
- ComfyUI 0.29.2
- comfyui-frontend-package 1.47.11
- Linux, GNOME / Wayland
- NVIDIA RTX 5090 32 GB, driver 595.84, CUDA 13.2
- torch 2.10.0+cu130, Python 3.13.12
- The display is driven by the same GPU used for inference

## Reproduction

1. Run a workflow whose models approach total VRAM. Here, Flux: the backend logs `Flux … 22700MB Staged` and `FluxClipModel_ … 9318MB Staged` on a 32.6 GB card.
2. When the run completes, pan or zoom the canvas.

Node bodies are gone; links still render; panning is seconds per frame.

## Measurements

Framebuffer of the `comfyui-desktop` GPU process, via `nvidia-smi pmon -s um`:

| State | Backend VRAM | Free VRAM | Desktop GPU proc fb |
|---|---|---|---|
| Healthy idle | — | — | 109 MB |
| Healthy, canvas active | — | — | 387–1336 MB |
| Degraded, after Flux run | 23,674 MB | 2.68 GB | **81 MB** |
| Degraded, with `--reserve-vram 2` | 25,210 MB | 3.88 GB | **29 MB** |

Freeing the models via `POST /free {"unload_models":true,"free_memory":true}` (backend 23,674 → 762 MB, free VRAM 2.68 → 25.6 GB) let the renderer re-acquire textures on its own — fb went 81 → 387 MB and the nodes reappeared.

**But that recovery is not reliable.** In the `--reserve-vram 2` row above there is **3.88 GB free and the renderer still does not re-acquire**. So this is not simple ongoing starvation — it is a failure to recover from a *transient* one. Memory becomes available again and the GPU process stays collapsed at a 29 MB framebuffer indefinitely.

## Expected

Either the renderer should not lose its composited layers under transient VRAM pressure, or it should re-acquire them once memory is available again.

At minimum `Ctrl+R` should rebuild the GPU context. Today the reload restarts the renderer while the shared GPU process persists in its degraded state, so the reload is a no-op for this failure — which makes the problem look unfixable from the user's side.

## Workarounds tried

| Workaround | Result |
|---|---|
| `Ctrl+R` / F5 / title-bar refresh | no effect |
| `--reserve-vram 2` | measurably better (3.88 GB free vs 2.68 GB), nodes still disappear |
| Unload models via `/free` | sometimes recovers, sometimes not |
| Full quit and relaunch | always works, unloads all models |
| **Run the UI in an external browser** | **no failure at all** |

The last row is the useful one: `launchMode: "console"` plus a normal browser tab is a complete workaround, and also the clearest evidence that the defect is in the Electron renderer's GPU context handling rather than in the frontend.

Reproduce the failure in ComfyUI Desktop 1.0.34 after the documented Flux VRAM-heavy run, then compare the Electron renderer with an external browser at 127.0.0.1:8188. Start by investigating the Electron GPU process and renderer reload behavior described in the issue. Done means node bodies recover after transient VRAM pressure or Ctrl+R reliably rebuilds the GPU context without a full relaunch.

Written by the indexing model from the issue text.