Fix: LAN-only printer unreachable when Studio stays on cloud MQTT

[ClusterM]

Fix: LAN-only printer unreachable when Studio stays on cloud MQTT

Summary

This happens when the printer is in LAN-only mode (real LAN-only: no
path to Bambu cloud MQTT) while the user is logged into a Bambu account.
Studio can still put the device on the cloud MQTT path; the printer cannot
answer there, so a usable connection cannot be established at all — Studio
waits for cloud replies that the printer can never send.

Even with a working local path (SSDP + access code) — and even though Studio
largely knows the printer is local — it still waits for replies on cloud
MQTT and effectively ignores the matching LAN replies for UI readiness.
Local MQTT delivers get_version / push_status, but the UI never becomes
ready.

Symptom: replies are parsed in logs, but is_info_ready() reports
failed to check version because it checks a different MachineObject
whose module_vers is still empty. Logging out of the account removes the
cloud object and the problem disappears.

This PR prefers the LAN path whenever a direct LAN machine entry exists for
the same dev_id, and routes selected-machine / MQTT handling through that
same object so Studio no longer depends on cloud MQTT that a LAN-only printer
cannot reach.

Root cause

Studio keeps two maps of printers:

• userMachineList — devices from the logged-in account (cloud)
• localMachineList — devices discovered on the LAN (SSDP), with access code

For the same serial/dev_id, both maps can hold separate MachineObject
instances.

Previously:

1. get_my_machine_list() preferred the cloud entry when both existed, and
   only added the LAN entry if the cloud key was absent.
2. get_selected_machine() always looked up userMachineList first.
3. LAN MQTT (set_on_local_message_fn) parsed into get_my_machine() (often the
   local object after SSDP marked connection type as lan).
4. Outgoing publish_json() also followed is_lan_mode_printer() on the object
   used by the send dialog — so commands went out on local MQTT.
5. UI readiness (is_info_ready(), sidebar sync) used get_selected_machine() —
   the cloud object — whose module_vers / push counters never updated.

Timeline matching the bug logs:

publish_json(get_version)          → local MQTT (LAN object)
get_version :product_name=...      → parse_json on LAN object (module_vers filled)
is_info_ready: failed to check version
                                   → check on cloud object (module_vers empty)

When the printer is LAN-only (no Internet / no cloud MQTT), cloud state never
arrives, so the cloud object stays empty indefinitely. Logging out removes
userMachineList, so only the LAN object remains and everything works.

Change

1. Prefer LAN in get_my_machine_list()

Build the list from localMachineList first (LAN + access code + available).
Only then add cloud entries from userMachineList, and do not override an
existing LAN entry for the same dev_id.

2. Align get_selected_machine() with that list

Return get_my_machine(selected_machine) first so the selected printer is the
same MachineObject used for LAN publish/parse and for UI readiness checks.

3. Ignore cloud MQTT while the device is on the LAN path

In GUI_App::init_networking_callbacks() cloud message handler: if
get_my_machine(dev_id) is a LAN-mode printer, skip applying cloud payloads to
userMachineList. Direct LAN connection owns device state.

4. Match LAN UI updates by dev_id, not pointer equality

LAN message handler previously required get_selected_machine() == obj. After
the dual-object split that comparison failed even for the correct device.
Compare sel->get_dev_id() == dev_id instead.

Files changed

• src/slic3r/GUI/DeviceCore/DevManager.cpp — prefer LAN in machine list;
  get_selected_machine() uses the canonical get_my_machine() object.
• src/slic3r/GUI/GUI_App.cpp — skip cloud MQTT for LAN-owned devices; fix LAN
  sidebar update matching by dev_id.

Test plan

• Log in to a Bambu account. Use a LAN-only printer (no cloud access /
  no Internet to Bambu MQTT) on the same LAN with a valid access code.
• Select the printer and open Send / Device flows that wait on
  is_info_ready(). Confirm it becomes ready (no stuck "Reading…" /
  timeout) after get_version + push_status.
• Confirm logs show local publish_json and matching get_version parse,
  and that is_info_ready no longer reports failed to check version
  immediately after a successful parse.
• Log out of the account and repeat — still works (regression check).
• With a normal cloud-online printer (Internet OK, no conflicting LAN-only
  path), confirm Device tab / send still update via cloud MQTT as before.
• Switch between LAN and cloud printers; confirm no cross-talk of AMS /
  sync badges between devices.