fix: Watchdog wirksam machen, Factory-Reset im App-Task, Resetzähler-Retry

- vApplicationIdleHook() füttert den Watchdog nicht mehr (sdk/Platform/Sys/wm_main.c,
  dokumentiert als Patch 4 in sdk/PATCHES.md). Bisher fütterte der Idle-Task den
  Watchdog bei jedem Leerlauf, auch wenn ein Task deadlockt (z.B. nl_app_lock() hält
  und nie freigibt) - der Watchdog konnte so nie greifen.
- Neues Konsolenkommando `wdtest` (Parser in nl_console_cmd.c/.h, Ausführung in
  nl_console.c, Host-Test in test_console_cmd.c): hält nl_app_lock() für immer, damit
  light_task und app_task blockieren und nur der Watchdog-Reset den Chip retten kann.
- nl_app_request_factory_reset() (nl_app.h) setzt nur ein volatile Flag; app_task
  prüft es in der Hauptschleife und ruft nl_app_factory_reset() selbst auf, da nur der
  App-Task die Flash-Stores besitzt. Das Konsolenkommando `factory` ruft jetzt diese
  Funktion statt nl_app_factory_reset() direkt aufzurufen, um die Race mit
  nl_state_log_append()/nl_resetcnt_clear() im App-Task zu vermeiden. Der Bootpfad
  (Bootzähler >= 5) ruft weiterhin direkt nl_app_factory_reset() auf.
- nl_resetcnt_clear() wird nur noch als erledigt markiert, wenn es 0 zurückgibt, damit
  ein fehlgeschlagener Clear in der nächsten Schleifeniteration erneut versucht wird.

sdk/PATCHES.md

@@ -14,3 +14,14 @@ Lib/GNU, Bin/secboot.img, Tools/GNU/link_w600_2m.ld (→ ld/) und wm_tool.c (→
    (`qconnex_sdk/src/qc_main.c`) war `pre_gpio_config()` bereits ein No-Op; `EarlyInit()` rief dort nur
    in die QConnex-Hardwareschicht (`QCXH_EarlyInit()`), die ninlight nicht verwendet. Board-spezifische
    Frühinitialisierung (falls nötig) folgt in einem späteren Plan.
+4. `Platform/Sys/wm_main.c`: `vApplicationIdleHook()` hat bisher jedes Mal `tls_watchdog_clr()`
+   aufgerufen, wenn der Idle-Task lief - also immer dann, wenn kein anderer Task rechenbereit war.
+   Ein Task-Deadlock (z.B. ein Task, der `nl_app_lock()` hält und nie freigibt) hätte den Watchdog
+   damit nie ausgelöst, weil der Idle-Task munter weiter gefüttert hätte. Der `tls_watchdog_clr()`-
+   Aufruf wurde entfernt; `wfi` bleibt. Der einzige verbleibende `tls_watchdog_clr()`-Aufruf im SDK
+   ist in `Platform/Common/fwup/wm_fwup.c` (Firmware-Update-Task) - das ist unkritisch, da er nur
+   während eines laufenden OTA-Updates feuert und den `app_task`-Heartbeat in `src/app_main.c`
+   nicht ersetzt (der Watchdog wird sonst ausschließlich dort über den `s_light_beat`-Heartbeat
+   des `light_task` gefüttert). Getestet mit dem Konsolenkommando `wdtest`
+   (src/sys/nl_console_cmd.c, src/sys/nl_console.c): es hält `nl_app_lock()` für immer, wodurch
+   `light_task` und `app_task` blockieren und der Watchdog den Chip zurücksetzen muss.