fix(mqtt): stop tryConnect() log-flood when MQTT host is unconfigured

[jace]

Problem

When WiFi is connected but no MQTT host is configured, tryConnect() spins on every loop() iteration — re-reading NVS and emitting an error log each time.

tryConnect() early-returns on an empty host without advancing s_nextTryMs:

if (netwifi::state() != netwifi::State::Connected) return;
String host = settings::getMqttHost();
if (host.length() == 0) return;   // <-- s_nextTryMs never advanced

loop() only calls tryConnect() when millis() >= s_nextTryMs. Since the empty-host path leaves s_nextTryMs untouched, it fires every iteration (~60 ms). Each call re-reads mqtt_host from NVS, and the ESP Preferences layer logs nvs_get_str len fail: mqtt_host NOT_FOUND at error level — flooding the serial/remote log (~16 lines/sec) indefinitely for any WiFi-up-but-MQTT-unconfigured deployment (the default for anyone using WiFi/OTA without MQTT).

Fix

Give the "host not configured" branch the same backoff discipline the genuine-failure path already has: set a 60 s retry window before returning. A minute-scale recheck still picks up credentials set later without spinning.

Verification

Bench-tested on a XIAO ESP32-C3, WiFi associated, no MQTT host set:

	mqtt_host NOT_FOUND lines / 14 s
before	~250
after	1

The configured-MQTT path is untouched (no behavior change when a host is set), and the recheck still self-corrects if credentials are added at runtime.

🤖 Generated with Claude Code

[jace]

Hello! I'm building FlashBee with a DFRobot lightning sensor instead of a Seeed Studio Grove sensor as I couldn't find one. I asked Claude Code to run the tests for hardware compatibility, and in the process it spotted a small gap in the logic, when WiFi is configured but no MQTT server is configured.

I'll open a few more PRs for the things I find. Hope that's okay!