fix: remap mixed filament config on deletion

[wudi901]

Summary

• Add a reusable config remapping helper for mixed-filament deletion and merge flows.
• Apply the full old-to-new filament remap to global feature-filament keys and object/volume/layer extruder plus object/volume feature-filament overrides.
• Preserve the established explicit-zero default convention for cascade-deleted mixed rows.
• Add regression tests for plain shift-down deletion and cascade-mixed-to-default remapping.

Root cause

Painting already consumed PresetBundle's old-to-new filament remap, but config-level references still used the naive delete path. That path only replaces the deleted physical ID and decrements higher IDs. It cannot represent a mixed row becoming 0/default or a mixed target retaining a shifted virtual ID, so config references could remain stale.

Implementation

• MixedFilamentConfigRemap.hpp centralizes the five feature-filament keys, bounded old-ID lookup, DynamicPrintConfig feature-key remapping, and ModelConfig extruder/feature-key remapping.
• Plater::on_filaments_delete() uses those helpers whenever an explicit remap exists and retains the existing naive path otherwise.
• extruder = 0 remains an explicit default; deleted feature-filament overrides are erased so global defaults take effect.

Self-check

• Applied common review, SnapmakerOrca coding/workflow, integer/type safety, const correctness, testing, and scope-control harnesses.
• The changed orchestration function remains below the project's 150-line limit.
• New code uses project-preferred containers and static_cast; no raw C array or functional cast is introduced.
• No exceptions, concurrency changes, external input handling, credentials, or dependencies are introduced.

Tests

• Mixed filament config remap shifts object feature overrides
• Mixed filament config remap sends deleted mixed rows to default

These cover the plain non-mixed case (wall_filament: 5 -> 4 after deleting physical slot 2) and a cascade-deleted mixed row reverting to default.

Validation

• git diff --check
• CI is requested for commit 8ddd61786c.

[zhangzhend0ng]

Review: remap direction is right, but this regresses object/volume-level feature filament keys

The remap-based approach and the "explicit 0 = default" convention (mirroring the batch-match cleanup around Plater.cpp:2784-2813) look correct for the extruder key and the global feature keys. One blocking issue though:

🔴 Blocking: object/volume-level feature keys lose their shift-down handling

The five feature keys (wall_filament, sparse_infill_filament, solid_infill_filament, support_filament, support_interface_filament) exist at three levels: global print config (remapped by this PR ✅) and object/volume ModelConfig (no longer handled ❌).

• The naive decrement for the object/volume-level copies lived in update_filament_values_for_items_when_delete_filament (src/slic3r/GUI/GUI_ObjectList.cpp:887-918), which this PR skips entirely whenever should_remap_states is true.
• The replacement path update_objects_list_filament_column → update_filament_values_for_items only erases keys > filaments_count (GUI_ObjectList.cpp:704-708) — it never shifts.
• remap_config_extruder only touches the extruder key.

Note that should_remap_states is true for every deletion, not just mixed-filament ones: update_num_filaments builds a remap whenever a filament is deleted (src/libslic3r/PresetBundle.cpp:3909-3911), so the standard sidebar delete flow takes the new branch too.

Repro (no mixed filaments needed): 6 physical filaments, an object with a per-object override wall_filament = 5; delete physical #2.

• Before: naive decrement → wall_filament = 4 (correct).
• After this PR: the key is not remapped and stays 5; the new total is 5, so the > count clamp doesn't fire either. Value 5 now points at old slot 6 → walls silently print with the wrong filament.

These keys are user-settable per object/part (they come from PrintRegionConfig/PrintObjectConfig via SettingsFactory::get_options, GUI_Factories.cpp:160), so this is reachable through plain UI usage.

Suggested fix: in the should_remap_states branch, apply the same remap to the five feature keys on mo->config and mv->config (erase on mapped == 0, matching the global-key convention used in this PR). Layer ranges can stay extruder-only for parity with the old code.

🟡 Minor

1. plates_custom_gcodes extruders still use the naive decrement (Plater.cpp:22086+) — same bug class under mixed-row renumbering. Fine as a follow-up, but worth a tracking issue so it doesn't get lost.
2. remap_old_filament_id lacks the mapped > num_filaments defense-in-depth guard that the sibling sites carry (Plater.cpp:22043, :2780). The current remap builders keep values in range, so this is consistency/robustness only.
3. update_objects_list_filament_column(num_filaments) receives a total (physical + mixed) while its other callers pass a physical count, and total_filaments_count() adds the mixed count again (GUI_ObjectList.cpp:71-77) — double-add. It only weakens the belt-and-suspenders clamp today, but passing the physical count would match the function's contract.

Test ask

Please add (or manually document) a before/after check for the plain path: non-mixed project, per-object wall_filament set above the deleted slot. That's exactly the case mixed-color-only testing wouldn't catch.