[blb4github]

Problem

Slow, intermittent, or disconnected browser clients could make synchronous ESP32 HTTP socket writes hold the HeishaMon main loop for seconds, delaying heat-pump control, rules, and MQTT processing.

Solution

• Stage outgoing HTTP bytes per client so short/nonblocking TCP writes can be resumed on later main-loop iterations.
• Bound each ESP32 HTTP TX attempt (MSG_DONTWAIT) and cap per-loop flushing, without changing the maximum of five web clients.
• Limit each client to a 4 kB staged buffer and close stalled clients after 5 seconds without progress.
• Preserve HTTP sendlist/chunk ordering; free staged buffers on client reset.
• Remove experimental DIAG WEB timing output while retaining actual queue/socket/stall error logs.

Validation

• Experimental ESP32-S3 firmware tested for ~15 h 23 min under intermittent VPN browser traffic: 853 resumed TCP writes, 44 stalled-client closures, 13 socket errors, no observed long DIAG WEB loop delays, overflows, or reboots, with ~180–195 kB heap.
• Subsequent LAN-oriented log showed stable operation, though QNAP Browser Station was not persistently connected; not a continuous LAN stress run.
• Isolated ESP8266/ESP32 compile checks have passed after diagnostic cleanup.
• The final diagnostics-cleaned version has not yet had a separate long-duration hardware regression test.

Scope

Changes only HeishaMon/src/common/webserver.cpp and .h. Configurable GPIO is proposed independently.