Fix pool DNS resolution: don't cache 0.0.0.0 when hostByName fails

[Gheop]

Problem

checkPoolConnection() in mining.cpp ignores the return value of WiFi.hostByName(). On the ESP32 Arduino core, hostByName() returns 0 and writes 0.0.0.0 into the result when resolution fails (WiFi just came up, transient DNS timeout, slow/lossy link…).

Since the result is trusted unconditionally, a failed first resolution caches 0.0.0.0 in serverIP. The miner then keeps calling client.connect(0.0.0.0, port), which can never succeed: WiFi shows connected but the pool never sees the worker, and only a reboot recovers (and only if resolution happens to succeed on that boot).

This matches several reports of miners that join WiFi but never show up on the pool: #169, #247, #706, #583.

Serial log of the failure:

[E] hostByName(): DNS Failed for public-pool.io
Resolved DNS and save ip (first time) got: 0.0.0.0
Imposible to connect to : public-pool.io
Client: connected>false / subscribed>false / wificonnected>true   (looping)

Fix

• Check the return value of hostByName() (and guard against 0.0.0.0). On failure, keep serverIP at the unresolved sentinel (1.1.1.1) and return, so the next call retries a fresh resolution instead of caching a bad IP.
• On a failed client.connect(), reset serverIP to the sentinel so the next attempt re-resolves (also handles a pool IP change / stale entry) instead of re-resolving into the same variable and falling through.

Minimal change, no effect on the happy path.

Testing

Built and flashed on a LilyGo T-Display-S3 (env:NerdminerV2). A miner that previously stayed stuck on 0.0.0.0 after a failed boot-time resolution now recovers on its own and connects to the pool.