Re-enable WDT panic=true once the WDT-culprit task is tracked down

[torlando-tech]

Captured during the greptile review on #26.

Background

-DCONFIG_ESP_TASK_WDT_PANIC=false (or equivalent) is currently in pyxis's build config because some task on the t-deck was tripping the task watchdog under specific stress patterns, and a full panic-on-WDT reboot was disruptive enough during early bring-up that we silenced it to "just log + soldier on". Context in ~/Documents/Obsidian/columba-vault/80 Assistant/Memory/pyxis/pyxis_microReticulum_graft_spike_findings.md.

Why this matters

Silencing the WDT panic means a stuck task can hang the device indefinitely instead of recovering via reboot. That's the wrong default for shipping firmware — a stuck UI / RNS-loop / BLE task should reboot in a few seconds, not require physical power-cycle.

Suggested resolution

1. Identify the WDT-culprit task(s). Likely candidates: the RNS loop (microReticulum's Transport.loop and jobs in the main Arduino task), the LVGL renderer if a screen swap pegs the CPU, or the BLE NimBLE task during multi-peer scan+connect storms.
2. Fix the offender(s) — usually a missing esp_task_wdt_reset(), a long-running blocking call, or a tight loop without vTaskDelay.
3. Flip CONFIG_ESP_TASK_WDT_PANIC back to true (or remove the override) so production builds reboot on stuck-task.

Acceptance

• All long-running tasks (Reticulum::loop host loop, LVGL refresh, BLE main loop, AutoInterface RX) verified to feed the WDT or yield with frequency < the timeout (default ~5s).
• Build flag change committed.
• Full conformance suite (tests/native/test_*.py) still passes.
• 1h soak on hardware without WDT trips.