Watchdog timeout silently stays at the core's 5 s: esp_task_wdt_init fails 'TWDT already initialized' #285

Seen on um_feather running d6fa305 (2026-09-08, #283): the board reboots every ~70 s.

E (33470) task_wdt: esp_task_wdt_init(517): TWDT already initialized
Watchdog enabled: 30s timeout
...
E (68435) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (68435) task_wdt:  - loopTask (CPU 1)
E (68435) task_wdt: Tasks currently running: CPU 0: IDLE0  CPU 1: IDLE1
E (68435) task_wdt: Aborting.

Cause, verified: the pinned core's sdkconfig (framework-arduinoespressif32-libs esp32s3/qio_qspi) has CONFIG_ESP_TASK_WDT_INIT=1 and CONFIG_ESP_TASK_WDT_TIMEOUT_S=5, so the task watchdog is already running at 5 s when setup() calls esp_task_wdt_init with the 30 s config (src.ino ~249). That call returns ESP_ERR_INVALID_STATE, the return value is not checked, the 'Watchdog enabled: 30s timeout' line is printed anyway, and esp_task_wdt_add(NULL) subscribes loopTask to the 5 s watchdog. The WiFi reconnect path (web.cpp ~96-103: WiFi.reconnect() then a blocking attempts<10 wait loop) runs from loop() every WIFI_RECONNECT_INTERVAL and blocks longer than 5 s, so the watchdog resets the chip. It never showed on the Adafruit board because WiFi connected there; it will show on any board that cannot join WiFi, which is every build from main today (placeholder credentials).

Fix: when esp_task_wdt_init returns ESP_ERR_INVALID_STATE, call esp_task_wdt_reconfigure(&wdt_config) (IDF 5.x API) and log the return value; print the actual effective timeout, not the requested one. The blocking reconnect loop is a separate smell and is left alone here.

Test, falsifiable: after the fix the boot log prints the reconfigure result and no 'TWDT already initialized' error, and the board runs past 70 s and through several WiFi reconnect attempts without a task_wdt reset.