fix: heater task permanently died after a mid-brew unplug, never recovered

Root cause (from the brewpi Pi's log): HendiCtrl.disconnect() only
caught HendiException (a protocol-level NAK), but a genuine unplug
fails deep inside pyserial itself - flushInput()/readline() raise
termios.error/OSError on the now-dead fd. That escaped disconnect()
uncaught (skipping self.ser.close() too), then kept propagating up
through every caller that invoked disconnect() from its own except
handler (HeaterHendi.process()/activate(), AHeater.open()'s
context-manager exit), all the way out of HeaterTask.on_process()'s
coroutine entirely. Nothing restarts a dead ATask, so the heater's
process()/duty-cycle loop was gone for the rest of the process's
life - reconnecting afterward changed `connected` back to True but
nothing was left running to ever call process() again.

Fixes:
- HendiCtrl.disconnect() now catches broadly and always closes the
  port, matching Pololu1376.disconnect()'s already-correct pattern.
- HeaterTask/StirrerTask.on_process() gain an outer retry loop as a
  safety net: even an unanticipated exception now logs, marks
  disconnected, and re-enters rather than permanently killing the
  task.

Verified by reproducing the exact failure (comm error raising a raw
OSError, not HendiException) against a fake device - the task now
survives and resumes process()ing once reconnected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YaPLuRPpyjWcwhMvCvpHCL

components/actor/hendiCtrl.py

@@ -213,9 +213,23 @@ class HendiCtrl:
 		if self.ser.is_open:
 			try:
 				self.remoteEnable(False)
-			except HendiException:
+			except Exception:
+				# Not just HendiException (a protocol-level NAK) - a genuine
+				# unplug fails deep inside pyserial itself (termios.error/
+				# OSError from flushInput()/readline() on a dead fd), and
+				# disconnect() must never let that escape: every caller here
+				# (HeaterHendi.process()/activate()'s own except handlers,
+				# AHeater.open()'s context-manager exit) calls disconnect()
+				# specifically to recover from a comm failure, so if this
+				# raises too it propagates all the way out of HeaterTask's
+				# on_process() and permanently kills that task's loop - the
+				# device then never gets process()'d again even after a
+				# later successful reconnect.
+				pass
+			try:
+				self.ser.close()
+			except Exception:
 				pass
-			self.ser.close()
 		self.sw_id = None
 		self.sw_ver = None