fix: prevent gallocr hash overflow in tiny graph-cut segments

[fszontagh]

Summary

build_segment_graph() sized each segment graph from internal_node_indices + input_refs, but ggml_gallocr hashes more tensors than that: a view-typed input leaf's view_src is a distinct tensor it must hash, even though it is marked external and never allocated.

gallocr sizes its hash set to (n_nodes + n_leafs) + (n_nodes + n_leafs)/4. The 25% margin normally absorbs the extra tensor, but on a one-node segment the integer division yields zero margin, so 4 distinct tensors overflow a 3-slot hash and ggml_hash_find aborts.

The segment graph now registers every tensor gallocr will hash - leaf view_srcs, plus any node src/view_src not already present - so the count covers them. External tensors are hashed but never allocated, so measurement is unchanged.

Related Issue / Discussion

Fixes the crash reported in #1788.

#1788 also reports mosaic/blank output on the CPU path. That is a separate bug and is not addressed here, so the issue should stay open after this lands.

Additional Information

Reproduced on CUDA (RTX 3060) with an edit model that uses the Qwen2.5-VL vision encoder (Qwen-Image-Edit-2509, LongCat-Image-Edit) and --offload-to-cpu --max-vram -1 --stream-layers. It aborts at ggml/src/ggml-impl.h:318 immediately after resize conditioner ref image, and the process then hangs.

Instrumented segment at the point of failure:

seg#34  n_nodes=1  n_leafs=2  distinct=4  min_hash=3  -> OVERFLOW

A patched vs unpatched A/B on regular (non-edit) Qwen streaming produced byte-identical output, so the change is numerically inert. With the patch the abort and hang are gone and the edit pipeline runs to completion.

Checklist

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