[Feature]: per-Virtual-Printer 'Save AMS mapping' toggle + reprint auto-apply from saved mapping

[Striker72rus]

Problem or Use Case

When a print is queued through a Virtual Printer from a slicer (e.g. OrcaSlicer/Bambu Studio), the slicer's AMS/tray-to-filament mapping is currently not preserved anywhere. When the resulting archive entry is later reprinted, the user has to manually re-map every filament slot again, even though the original slicer mapping is still known at print time and is very likely still correct (same physical spools/AMS layout). This gets repetitive for anyone who reprints the same models regularly.

Proposed Solution

• Add a new per-Virtual-Printer setting, save_ams_mapping (bool, default off), configurable from the Virtual Printer card in the frontend.
• When enabled, persist the slicer's AMS mapping (slicer_ams_mapping, array indexed by slicer tool index) into archive.extra_data at the time the print is added to the queue / restamped.
• The mapping is written only while the toggle is on, but is read unconditionally on reprint — turning the toggle off later does not erase previously saved mappings, it only stops recording new ones.
• On the reprint / queue-edit filament-mapping screen, show a "Mapping" toggle button whenever a saved mapping exists for the archive. Clicking it snaps every filament-slot assignment straight to the saved mapping (matched by the slicer's tool index against the target printer's AMS layout), instead of the existing color/material best-effort auto-match. Clicking again reverts to the auto-match result.
• Show an "AMS mapping saved" badge on archive entries that have a stored mapping, so it's visible before opening the reprint dialog.

Scope:
Backend — backend/app/models/virtual_printer.py (new column + migration), backend/app/api/routes/virtual_printers.py, backend/app/services/virtual_printer/manager.py (_add_to_print_queue / _restamp_recent_queue_item), backend/app/services/archive.py.
Frontend — frontend/src/components/VirtualPrinterCard.tsx, frontend/src/components/PrintModal/FilamentMapping.tsx (+ types.ts, index.tsx), frontend/src/pages/ArchivesPage.tsx.

Alternatives Considered

A global "require exact filament match" setting was prototyped first but reverted — it changed scheduler/queue matching semantics broadly instead of solving the actual pain point (repetitive manual remapping on reprint), and was a bigger behavior change than needed.

Feature Category

Print Queue & Scheduling

Priority

Would improve my workflow

Mockups or Examples

No mockups — the affected UI is the existing filament-mapping screen in the reprint/queue-edit dialogs; the change adds a small toggle button next to the existing filament rows.

Contribution

• I would be willing to help implement this feature

Checklist

• I have searched existing issues to ensure this feature hasn't already been requested

[maziggy]

Please note our rules from CONTRIBUTING.md. Thanks!

[ForgeFriend]

Related P1S finding from a ForgePrint integration: saving and replaying ams_mapping should solve application-driven reprints, but the printer's own LCD Print Again path has no application command available to replay it. BambuStudio issue #5756 reports the same failure mode.

In a controlled single-material test on a P1S running firmware 01.10.00.00, we generated a separate .gcode.3mf whose embedded logical filament identity matched the desired physical tray. The source used logical filament 1 with a command-time mapping to physical AMS slot 4. The test variant changed the executable selection and matching metadata to logical filament 4 (M620 S3A, T3, and M621 S3A) and regenerated the embedded G-code MD5. After the initial print, we restarted the P1S and selected the retained job from the printer LCD. It correctly used physical AMS slot 4 again.

This is one successful P1S/firmware observation, not yet a cross-model guarantee. Our prototype is deliberately limited to one sliced plate and one used filament, writes a distinct output instead of overwriting the source, bounds and validates the 3MF ZIP, allowlists the six changed entries, verifies every unchanged entry by hash, and rejects ambiguous or multi-material inputs.

Would you prefer this panel-reprint compatibility finding to stay in #2684, or should it be a separate feature request? If it fits BAMBuddy's direction, we can provide a sanitized metadata fixture and the exact transformation and verification rules before discussing a pull request.