fix: move WiFi handling after BLE command queue processing (#30)

In v1.6, handleWiFiServer() and the WiFi reconnection check were moved
to the top of loop(), before BLE command/response queue processing.
This can cause BLE commands to sit unprocessed in the queue when
handleWiFiServer() blocks or takes a slow path, resulting in BLE
timeouts for clients (Home Assistant integration, py-opendisplay).

Observed symptoms:
- BLE READ CONFIG commands queued but never processed
- 'ESP32: Command queued for processing' appears in serial log but
  'ESP32: Processing queued command' never follows
- Home Assistant integration fails with 'ble_timeout' during device
  interrogation
- py-opendisplay image uploads timeout after 10s

This commit moves WiFi handling back to after the BLE command queue
drain and response notification loop, restoring the v1.3 execution
order where BLE is always serviced first. WiFi functionality is
preserved — only the ordering within the loop iteration changes.

Co-authored-by: Oz <oz-agent@warp.dev>

Author: sweidinger

src/main.cpp

@@ -113,22 +113,6 @@ void setup() {
 void loop() {
     processLedFlash();
     #ifdef TARGET_ESP32
-    handleWiFiServer();
-    static uint32_t lastWiFiCheck = 0;
-    if (wifiInitialized && (millis() - lastWiFiCheck > 10000)) {
-        lastWiFiCheck = millis();
-        if (WiFi.status() != WL_CONNECTED && wifiConnected) {
-            writeSerial("WiFi connection lost (status: " + String(WiFi.status()) + ")");
-            wifiConnected = false;
-            if (wifiServerConnected) {
-                disconnectWiFiServer();
-            }
-        } else if (WiFi.status() == WL_CONNECTED && !wifiConnected) {
-            writeSerial("WiFi reconnected (IP: " + WiFi.localIP().toString() + ")");
-            wifiConnected = true;
-            restartWiFiLanAfterReconnect();
-        }
-    }
     if (woke_from_deep_sleep && advertising_timeout_active) {
         if (pServer && pServer->getConnectedCount() > 0) {
             writeSerial("BLE connection established - switching to full mode");
@@ -188,6 +172,24 @@ void loop() {
             cleanupDirectWriteState(true);
         }
     }
+    // WiFi handling runs after BLE queue processing to avoid blocking
+    // BLE command responses (moved from top of loop in v1.6 fix).
+    handleWiFiServer();
+    static uint32_t lastWiFiCheck = 0;
+    if (wifiInitialized && (millis() - lastWiFiCheck > 10000)) {
+        lastWiFiCheck = millis();
+        if (WiFi.status() != WL_CONNECTED && wifiConnected) {
+            writeSerial("WiFi connection lost (status: " + String(WiFi.status()) + ")");
+            wifiConnected = false;
+            if (wifiServerConnected) {
+                disconnectWiFiServer();
+            }
+        } else if (WiFi.status() == WL_CONNECTED && !wifiConnected) {
+            writeSerial("WiFi reconnected (IP: " + WiFi.localIP().toString() + ")");
+            wifiConnected = true;
+            restartWiFiLanAfterReconnect();
+        }
+    }
     #ifdef TARGET_ESP32
     const bool wifiLanSession = wifiInitialized && wifiServerConnected && wifiClient.connected();
     #else