[Ptitlouis6012]

What this changes

A LAN Bambu (or Anycubic) that is switched off restarted the box in a loop.

WiFiClientSecure waits thirty seconds for a host that does not answer (_timeout = 30000, then a select on the TCP connect in ssl_client.cpp), and the loop watchdog is LOOP_WDT_S = 30. The setSocketTimeout(4) and setHandshakeTimeout(5) set beside it bound neither: the connect has its own limit. So a printer that was off froze the loop for the whole wait, the watchdog fired, the box restarted and tried the same printer again — a restart every ~50 s until the printer was turned on. In between the touch was dead, and the account icon stayed orange because its exchange could never finish.

The fix is one call where each client is set up:

• backend_bambu.cpp: net_.setTimeout(4), a printer on the LAN answers in milliseconds.
• backend_anycubic.cpp: the same, for a LAN Anycubic.
• bambu_cloud.cpp: setTimeout(8), the broker is across the internet.

The Anycubic cloud session (LegacyTlsClient) already bounds its connect to 5 s, and the Elegoo, FlashForge, Creality and Snapmaker paths do not use WiFiClientSecure.

What you tested it on

A TigerSpool (ESP32-S3-Touch-LCD-2) on firmware 1.72.0 with a K2 and a P2S (LAN mode) in the account.

• Before: with both printers off, [link] attempt 1/5 to P2S, [bambu] connecting to 192.168.1.4:8883..., then task_wdt: loopTask and a reboot, every ~50 s, over 80 s of serial log (4 reboots).
• After: the same state, 100 s of log: 13 connect attempts, each failing in about four seconds (Bambu: MQTT rc=-2), the link gives up after five tries and retries as it always did, 0 watchdog resets. The touch works and the account icon is green. With the printers on it starts as before (2 link(s) up).

What is not fixed: while a printer stays unreachable each attempt still blocks the loop for up to four seconds, so the screen answers within about four to six seconds rather than instantly (a request took 5.7 s, a tap 4.4 s). That is far better than a freeze and a restart, but a probe that does not block the loop would be the real answer; I kept this change to the one line that stops the restarts.

Not tested: a K2 off on its own, and the Creality and Snapmaker paths. bash scripts/verify.sh --quick passes except "generated files match their generator", which also fails on a clean main on the machine used.

Checklist

• One concern. A rename and a behaviour change in one diff cannot be reviewed.
• English — comments, identifiers, log messages.
• No credentials, keys or tokens added anywhere.
• Any hardware constant carries a comment saying what breaks without it.
• Docs updated if behaviour changed. (no documented behaviour changes)
• CHANGELOG.md updated for anything user-visible. (left to the release ritual)