Read the CPU temperature instead of the alarm threshold beside it

lm-sensors prints high= and crit= on the same line as the reading, so scraping
the line for its largest number reported a flat 100C on Intel while the shell's
last-field parse got a bare ")" and never fired at all. One parse in the
adapter now, preferring Tdie over Tctl since Tctl carries a +27C offset.

Watchdogs/stability_watchdog.sh

@@ -737,12 +737,11 @@ echo "━━━ $ICON_REBOOT Stability Watchdog — $(date '+%Y-%m-%d %H:%M:%S')
 
     # ── CPU temperature ───────────────────────────────────────────────────────────────────────
     if [[ "$SYS_WATCHDOG_CHECK_CPU_TEMP" == true ]]; then
-        CPU_TEMP=""
-        if command -v sensors >/dev/null 2>&1; then
-            CPU_TEMP=$(sensors 2>/dev/null | \
-                grep -i "Package id 0\|Tctl\|CPU Temp" | \
-                awk '{print $NF}' | tr -d '+°C' | head -1)
-        fi
+        # Was a local sensors scrape taking the line's last field, which on a board that prints
+        # "(high = +80.0 C, crit = +100.0 C)" is the literal ")" — so this check has been reading
+        # nothing and never firing on HOST2. The adapter owns the parse now; both halves of
+        # Varaverk read the same number by construction. See platform_get_cpu_temp().
+        CPU_TEMP=$(platform_get_cpu_temp 2>/dev/null || true)
         if [[ -n "$CPU_TEMP" ]]; then
             CPU_TEMP_INT=$(printf "%.0f" "$CPU_TEMP")
             TRIGGERED=false