fix: re-clamp streaming VRAM budget to currently free memory - #1878

Summary

With --stream-layers, resolve_graph_cut_plan() re-measures free VRAM on every call and clamps the budget to it, then discards that value: the ratchet restores observed_max_effective_budget_ whenever the fresh measurement is lower. The first measurement wins for the lifetime of the runner, so once another model or another process takes VRAM, the planner plans against memory that is gone and the allocation fails.

Now the remembered budget is capped by what is free at that moment. free_clamp stays SIZE_MAX when the device is not measurable, so the unmeasured path is unchanged. Clamping at use rather than lowering the stored maximum lets the budget recover when the other consumer releases memory.

Related Issue / Discussion

None.

Additional Information

Seen on a 12GB card with two models loaded and a second CUDA process running:

qwen3    graph cut max_vram=9959.75 MB merged 36 segments -> 1 segments
z_image  graph cut max_vram=2489.94 MB merged 36 segments -> 9 segments
z_image  streaming budget = 9959.75 MB
...
qwen3    graph cut max_vram=9959.75 MB merged 36 segments -> 1 segments
ggml_backend_cuda_buffer_type_alloc_buffer: allocating 7480.09 MiB on device 0: cudaMalloc failed: out of memory

The second qwen3 plan reuses 9959.75 MB, measured when the GPU was still empty.

Checklist

• I have read and confirmed this PR follows the contribution guidelines.