fix(wifi): kurze Pause vor dem Standalone-Wechsel, Abnahmepunkt dazu

I6: Der HTTP-Task schreibt die 202 erst nach nl_api_handle(); die
Warteschlangennachricht geht aber schon darin raus, und net_task hat die
hoehere Prioritaet (35 gegen 42, im WM-SDK ist die kleinere Zahl hoeher). Er
verdraengt also sofort und reisst das Netz ab, bevor send_all() laeuft. Beim
Wechsel AUS dem WLAN kam die 202 trotzdem an, weil tls_wifi_disconnect()
asynchron arbeitet - ueber den eigenen AP ist tls_wifi_softap_destroy() der
haertere Abriss, und dieser Fall ist ungemessen.

Deshalb beides: rund 250 ms Pause im MSG_STANDALONE-Zweig vor dem Wechsel als
billige Versicherung, und der Fall als offener Punkt in der Abnahmeliste - die
Messung am Geraet bleibt noetig.

docs/hardware-checklist.md

@@ -76,6 +76,7 @@ Für den echten Flottenbau `NINLIGHT_RECOVERY_PASSWORD` und `NINLIGHT_TOKEN` in
 - [ ] Startpuls als Sichtprüfung: läuft beim Start rund 5 s und gibt danach das normale Einschaltverhalten frei; mit `pulse: false` entfällt er ganz — *Logik ist hostgetestet, am Gerät hat noch niemand hingesehen*
 - [ ] REST über den AP verlangt das Token (`GET system/settings` ohne Token → 401)
 - [ ] `{"enabled":false}` **ohne** gespeicherte WLAN-Daten → der AP heißt danach wieder `ninlight-<mac4>` (nicht mehr wie vom Nutzer gesetzt), und der Tokenschutz passt zur AP-Umschaltung: solange der Nutzer-AP steht, gilt das Token; sobald der Vorgabe-AP steht, ist `system/settings` wie im Onboarding offen. Gerätebeleg für C1 — bis dahin nur hostseitig durchdacht
+- [ ] Standalone-Daten ändern, während der Aufrufer **über den AP** verbunden ist → die 202 kommt beim Aufrufer an, bevor der AP abreißt. Im Code steht dafür seit I6 eine Pause von rund 250 ms vor dem Wechsel; **gemessen ist der Fall nicht** — beim Wechsel aus dem WLAN ging es auch ohne Pause gut, weil `tls_wifi_disconnect()` asynchron arbeitet, `tls_wifi_softap_destroy()` ist der härtere Abriss
 - [ ] WLAN eingeben, falsches Passwort → Gerät bleibt im eigenen AP mit eigenen Daten
 - [ ] WLAN eingeben, richtiges Passwort → Gerät im Heimnetz, nach einem Neustart **nicht** wieder im AP
 - [ ] Werksreset über 5× ein/aus → wieder unkonfigurierter Onboarding-AP

src/net/nl_wifi_w600.c

@@ -401,6 +401,16 @@ static void net_task(void *arg)
 
         if (m & MSG_NETIF)
             printf("wifi: netif event %u\r\n", (unsigned)(m & 0xFFu));
+        /* I6: Die 202 auf den Standalone-Wunsch schreibt der HTTP-Task erst, nachdem
+         * nl_api_handle() zurueck ist - die Warteschlangennachricht geht aber schon darin
+         * raus, und dieser Task hat die hoehere Prioritaet (35 gegen 42, kleinere Zahl heisst
+         * hoeher). Er verdraengt also sofort und risse das Netz ab, bevor send_all() lief.
+         * Beim Wechsel AUS dem WLAN ging das bisher gut, weil tls_wifi_disconnect() asynchron
+         * arbeitet; ueber den eigenen AP ist tls_wifi_softap_destroy() der haertere Abriss.
+         * Die Pause ist billige Versicherung - gemessen ist der AP-Fall damit nicht, er steht
+         * als offener Punkt in der Abnahmeliste. */
+        if (m == MSG_STANDALONE)
+            tls_os_time_delay(HZ / 4); /* ~250 ms */
         if (ignored_off)
             printf("wifi: standalone was already off, nothing to do\r\n");
         /* C1: Beim Verlassen des Standalone-Modus OHNE gespeicherte WLAN-Daten geht die