Fix third-party filaments unusable in AMS + remaining weight never updating (#11937)

[JaKuBisz]

Description

Fixes #11937: filaments manually added via the web Filament Manager showed
up in the manager list but appeared greyed out under "Unsupported
Filaments" in the AMS slot-assignment dialog and could not be selected.
Remaining filament weight also never updated after a print for non-RFID
spools.

Root cause

FilamentSpool::setting_id is compared everywhere against
Preset::filament_id, but the web "Add filament" dialog could persist a
cloud user-settings id, or nothing at all for a free-typed third-party
brand, instead of a real Preset::filament_id. There was also no
slicer-side consumption bookkeeping, so non-RFID spools (which always
report firmware remain = -1) never had their weight updated.

Changes

• libslic3r/PresetBundle: add resolve_filament_for_spool(), a tolerant
  lookup (filament_id → setting_id → vendor+type → "Generic ") used
  to make already-broken spools selectable instead of requiring an exact
  match.
• AMSMaterialsSetting.cpp: use the new resolver at all three gates
  (bucketing, confirm, fast-path) so previously "Unsupported" spools
  become selectable in the AMS slot dialog.
• Web Filament Manager Add/Edit dialog: reorder setting_id resolution to
  prefer filament_id over setting_id, with a fallback to a Generic
  preset id so setting_id is never persisted empty for a hand-typed
  brand.
• SelectMachine.cpp/.hpp: at print-send time, compute per-slot
  grams-used locally from the gcode result (LAN-safe, no cloud dependency)
  and record a pending consumption entry for the job.
• wgtFilaManagerStore/wgtFilaManagerSync: add a dedicated, idempotent
  deduct_consumption() path that applies pending consumption to the
  bound spool on the print FINISH transition, recomputing
  remain_percent/status locally, and pushes the update to the cloud
  immediately (guarded against being overwritten by a subsequent pull
  before the push confirms).
• wgtFilaManagerCloudSync.cpp: one-time backfill of broken setting_id
  for manually-entered spools during cloud pull (scoped to
  entry_method == "manual"/empty, so RFID-authoritative data is
  untouched); fixed cloud spool-list pagination that previously only ever
  fetched the first 20 spools.
• Fixed weight deduction never firing for background (non-selected)
  printers, and an MSVC-only build break (error C3493, constexpr lambda
  capture) introduced along the way.

All fixes are local-only (no cloud/RFID dependency for detection), so
behavior is correct in LAN-only mode too.

Testing

• Built for all platforms (Ubuntu 22.04/24.04/26.04, Windows x64, macOS
  universal x86_64+arm64) via the fork's Build All CI pipeline — all green:
  https://github.com/JaKuBisz/BambuStudio/actions/runs/33274025249
• Manually tested on Windows and macOS (Apple Silicon).

Related issues

Fixes #11937. The same problem is also reported in #11562, #11654 and
#11871. #12078 was closed as a duplicate (its investigation confirmed this
root cause), and #12079 is a minimal one-file variant — and mentioned this PR as the more
complete fix which should take precedence.

[maxbraketorque]

I sure hope this fix gets adopted by Bambu.

[XinZhangBambu]

@JaKuBisz Thanks for your contribution! We really appreciate the time and effort you've put into this PR to help improve our codebase.
could you please squash all the commits in this PR into a single commit? This will help us better track the changes and review the code more efficiently.
Once you've squashed the commits, we'll prioritize reviewing your PR as soon as possible. Thank you again for your support！

[JaKuBisz]

Done — all commits squashed into a single one. Thanks! @XinZhangBambu

[XinZhangBambu]

@JaKuBisz Thanks for squashing, and thanks for the detailed write-up.

We've received this and logged the underlying issue — the fix itself is
something we agree is needed. But the PR touches several core paths, so we'd
like to discuss internally whether this is the right shape for the fix before
moving forward. We'll come back to you with our conclusion.

Thanks again for the time and effort you put into this.