Unregister shell modifier volumes from the LOD sharing map before delete

[aceRage]

Description

Port of Snapmaker/OrcaSlicer #844 (merged).

GCodeViewer::load_shells() removes modifier volumes with a bare delete, but those volumes were already registered into the global LOD sharing map (g_meshVolumesMap) by load_object_volume(). Deleting them without calling release_volume() leaves dangling GLVolume* entries in the map.

When the same mesh is loaded again (for example switching back to a sliced plate), load_object_volume() can pick up the stale pointer as firstVolume and copy its shared_ptr<GLModel> LOD models, crashing in shared_ptr::operator= (use-after-free).

This change calls GLVolumeCollection::release_volume() before delete, matching the existing paths in clear() and the GLCanvas3D reload (P0-2) on Snapmaker/OrcaSlicer.

Only the modifier-removal loop in src/slic3r/GUI/GCodeViewer.cpp is touched.

Screenshots/Recordings/Graphs

N/A — no UI change.

Tests

• Diff matches Snapmaker/OrcaSlicer fix: unregister shell volumes from LOD sharing map before delete in l… Snapmaker/OrcaSlicer#844 exactly (4-line site change).
• No automated regression exists for this GUI volume lifetime path; full-app plate-switch reproduction (slice each plate, then switch plates back and forth on a multi-plate project with modifiers) is the upstream check.
• Compile note: EdgeSlicer main does not yet declare GLVolumeCollection::release_volume() or g_meshVolumesMap (LOD sharing from Snapmaker). This PR is the exact fix: unregister shell volumes from LOD sharing map before delete in l… Snapmaker/OrcaSlicer#844 site port and will compile once that API is present. Left as draft and not merged.

  

[aceRage]

Closing: the patch calls release_volume() and references g_meshVolumesMap, neither of which exists in this fork's GUI code, so it cannot compile as-is (review 2026-09-19). Reopen against the current LOD code if the dangling-volume case still reproduces.