refactor(firmware): separate acting on temperature from measuring it

Reading the sensor is inert. Reducing transmit power moves every RSSI the node
has, at both ends of every link -- introducing that during a three-to-nine node
bring-up would give any surprise two candidate causes and no way to separate
them.

So CONFIG_THERMAL_THROTTLE is now its own option, default off, while
monitoring stays on. The first flash therefore reports die temperature and
peak without ever changing behaviour, which is exactly what is needed to
answer whether these boards run hot in enclosures at all.

If none of them ever does -- the likely outcome at ~0.4 W average in a vented
box -- throttling never needs enabling and the thresholds cost nothing.

Co-Authored-By: claude-flow <ruv@ruv.net>
(cherry picked from commit 187eb17ba9549a96aa63ce0fda37888c8c65650c)

firmware/esp32-csi-node/main/Kconfig.projbuild

@@ -534,6 +534,19 @@ config THERMAL_MONITOR
       transition (~55-60 C) and sags slowly under its own weight, which never
       announces itself.
 
+config THERMAL_THROTTLE
+    bool "Act on the temperature by reducing transmit power"
+    depends on THERMAL_MONITOR
+    default n
+    help
+      Separate from monitoring on purpose. Reading the sensor is inert;
+      reducing transmit power moves every RSSI the node has, and doing that
+      mid-experiment gives any surprise two candidate causes.
+
+      Leave off until the fleet is stable and the logs show a node genuinely
+      running hot. If none ever does -- which is the likely outcome -- this
+      never needs enabling, and the thresholds below cost nothing.
+
 config THERMAL_WARN_C
     int "Warn above this die temperature (C)"
     depends on THERMAL_MONITOR

firmware/esp32-csi-node/main/thermal.c

@@ -133,12 +133,20 @@ void thermal_tick(void)
         s_state = next;
     }
 
+#ifdef CONFIG_THERMAL_THROTTLE
+    /* Acting on the reading is separate from taking it. Measuring is inert;
+     * changing transmit power mid-experiment moves every RSSI this node has,
+     * which is not something to introduce during a fleet bring-up when any
+     * surprise needs a single candidate cause. Turn this on once the fleet is
+     * stable AND the logs show a node actually gets hot -- if none ever does,
+     * it never needs turning on at all. */
     switch (s_state) {
     case THERMAL_CRITICAL:  apply_tx_power(TXP_MIN);   break;
     case THERMAL_THROTTLED: apply_tx_power(TXP_STEP2); break;
     case THERMAL_WARN:      apply_tx_power(TXP_STEP1); break;
     case THERMAL_OK:        apply_tx_power(TXP_FULL);  break;
     }
+#endif
 
     static int64_t s_last_log_us;
     int64_t now = esp_timer_get_time();