Fix release-build SIGSEGV in monotonic fill (stale right-horizontal link after vertical-run jump)

[gommzystudio]

Summary

Fixes a random release-build SIGSEGV in the monotonic fill traversal that we hit in production via top-surface ironing (Layer::make_ironing() → FillRectilinear). The same input would sometimes slice fine and sometimes crash, because the crash depends on which intersection carries the right-horizontal link.

Root cause

In both monotonic traversals in src/libslic3r/Fill/FillRectilinear.cpp (montonous_region_path_length and polylines_from_paths), iright accumulates the right-horizontal link while a vertical run is consumed:

• going up: iright = std::max(iright, it->right_horizontal()); inside the do-loop
• going down: if (int iright_new = it->right_horizontal(); iright_new != -1) iright = iright_new;

However, when the traversal follows a vertical_up() / vertical_down() link to continue on another run of the same vline (it = vline.intersections.data() + inext;), the landing intersection's right_horizontal() is never folded into iright.

If the only right link of the combined run lives at or after the landing point, iright remains -1 (or stale). The code afterwards does:

int inext = it->right_horizontal();
assert(iright != -1);
assert(inext == -1 || inext == iright);
const SegmentedIntersectionLine &vline_right = segs[i_vline + 1];
const SegmentIntersection *right = going_up ?
    &vertical_run_top(vline_right, vline_right.intersections[iright]) : ...

Both asserts are compiled out in release builds, so vline_right.intersections[iright] reads out of bounds with iright == -1 (crash), or traverses from a wrong intersection with a stale index (silent misbehavior).

Fix

Update iright at all four vertical-jump landing sites, using exactly the idiom the surrounding loops already use (max while going up, last non--1 while going down). Six added lines, no behavior change for paths that already computed a valid iright.

Validation

• Two different models reproduced the crash reliably, each triggering it through a different ironed top surface (per-object ironing overrides enable the affected code path). One of them failed 11/11 consecutive CLI slices on Ubuntu (SIGSEGV, exit 139; reported as exit 127 through the AppImage wrapper).
• With this patch applied to the unmodified v02.06.00.51 source, the same two models with unchanged zig-zag ironing passed 20/20 runs (10 per model), plus another 20/20 with the packaged AppImage.
• Output parity: identical ironing section counts per model before/after (107 and 5), identical estimated print times across repeats, full structural and spatial G-code validation (no missing regions).
• A core dump of the unpatched build shows the crash inside FillRectilinear during Layer::make_ironing().

The affected file is byte-identical between v02.06.00.51 and current master, so the bug is still present on master.

Notes

• The crash is timing-/geometry-dependent (which intersection ends up carrying the right link), which explains the "same input, random result" reports around monotonic surfaces.
• This may also be related to reports of identical CLI slices producing different results / silently missing extrusions (e.g. CLI: slicing is not run-to-run deterministic (survives CPU pinning + ASLR off) #11560, Arachne: self-intersecting layer polygons cause silent extrusion loss (missing cross-sections) and hangs in Release — 100% repro file + Debug asserts attached #11751), since a stale non--1 iright silently continues from the wrong intersection instead of crashing.