Add mash-schedule (Sud) automation: temp/rate sequencing + stirrer switching

brewpi.py had a dead -m/--model CLI arg and sude/*.json schedules were
pure data with no code to drive them, despite the README documenting
them as if they were already wired up.

Add components/sud.py's Sud, which loads a sude/*.json schedule and
steps through its Rasten (ramp -> hold -> optional wait-for-user ->
next rest), and tasks/sud.py's SudTask, which drives the temperature
controller's theta_soll/heatrate_soll from the current rest and
switches the stirrer between continuous (ramping) and intermittent
(holding, via stirrSpeedRast/stirrDutyRast/stirrCycleTime) operation.
Exposes progress on a new "Sud" WebSocket channel and accepts
Start/Confirm commands. Enabled via a new optional top-level "sud"
config key (see config.json.templ/.sim).

"Reached target" is detected via abs(theta_ist - theta_soll_set) <
tolerance rather than tc.state == HOLD, since the latter can still
read HOLD left over from the previous rest for one tick after a new
target is pushed (tc.state only updates on the controller's own,
independently-scheduled process() tick).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

README.md

@@ -38,6 +38,9 @@ components/                 Pluggable building blocks behind factories:
   actor/                       heater and stirrer drivers: simulated, a
                                 Hendi induction hob (serial protocol), or a
                                 Pololu 1376 stirrer motor controller
+  sud.py                       optional mash-schedule sequencer that steps
+                                through a sude/*.json schedule and drives
+                                the temperature controller from it
 
 tasks/                       Async tasks (one per component) that poll
                              hardware/sim state at a fixed interval and
@@ -46,7 +49,7 @@ tasks/                       Async tasks (one per component) that poll
 ws/                          Minimal WebSocket pub/sub layer: server
                              (single- and multi-user), client, and a
                              keyed message dispatcher (e.g. "Sensor",
-                             "Heater", "TempCtrl", "Stirrer", "Pot").
+                             "Heater", "TempCtrl", "Stirrer", "Pot", "Sud").
 
 tracer.py                    Logs traced variables to .mat files (for
                              offline analysis/tuning in MATLAB/Octave,
@@ -118,10 +121,27 @@ environment (`$WORKON_HOME`/`$BREWPI_HOME`) on a Raspberry Pi-style deployment.
 
 ## Mash schedules
 
-Files under `sude/` describe a brew's mash schedule: pot weight, malt/water
-weights, stirrer speed/duty, and a list of temperature rests, each with a
-target temperature, heating rate, and whether to pause for user confirmation
-before continuing (e.g. to add malt or check gravity).
+Files under `sude/` describe a brew's mash schedule ("Sud"): pot weight,
+malt/water weights, stirrer speed/duty, and a list of temperature rests
+("Rasten"), each with a target `temp`, `heatRate`, hold `time` (minutes), and
+whether to `waitForUser` before continuing (e.g. to add malt or check
+gravity).
+
+Set the top-level `sud` config key to a path under `sude/` (see
+`config.json.sim`/`config.json.templ`) to have the server step through it
+automatically: `components/sud.py`'s `Sud` tracks the current rest and
+`tasks/sud.py`'s `SudTask` drives the temperature controller's
+`theta_soll`/`heatrate_soll` from it, advancing once `theta_ist` settles
+close to the target and the rest's hold time has elapsed. It also switches
+the stirrer between the schedule's `stirrSpeedHeat` (continuous, while
+ramping) and `stirrSpeedRast`/`stirrDutyRast`/`stirrCycleTime` (intermittent,
+while holding), stopping it entirely during a `waitForUser` pause. It
+exposes progress (current rest, remaining hold time, state) on the `"Sud"`
+WebSocket channel and accepts `{"Sud": {"Start": true}}` to begin the
+schedule and `{"Sud": {"Confirm": true}}` to acknowledge a `waitForUser`
+pause and move to the next rest. Omit `sud` from the config to
+run without schedule automation (manual `theta_soll`/`heatrate_soll` control
+via the GUI, as before).
 
 ## Logging & analysis