fix(driver): detect profile drift, not just colour, after an AMS assign

[wolfrage76]

Summary

• Follow-up to fix(driver): re-push configure when a stale deferred config reverts the tray #13: the post-assign verify only compared tray colour, so a swap of two same-colour spools (e.g. red HS Matte vs red PLA+) kept the previous occupant's AMS code and PFUS with no re-push.
• Record the AMS code, setting_id, and colour actually configured per slot, and re-push once if the live tray's AMS code (or colour) disagrees.
• Clear a slot's cached params when a different spool takes it, so a later rebuild cannot resurrect the old occupant's PFUS.
• Suppress profile learning while the tray still contradicts the code we just configured, which was persisting the previous spool's AMS code onto the new filament.

Test plan

• Weigh a spool into a sticky AMS slot that just held a different spool of the same colour but a different profile — Filaman assigns correctly and Studio keeps the new spool's profile (not the previous occupant's)
• Watch logs for a one-shot WARNING tray overwritten after assign … AMS code … re-sending configure when the race occurs; no second re-push
• printer_write_mode / _apply_to_printer off: no verify re-push
• After a swap, the new filament's bambu_idx is not overwritten with the previous spool's AMS code
• pytest tests/test_profile_variants.py