Make grain_mass/water_mass per-step and re-derive plant params on change

grain_mass and water_mass now live on each step (defaulted from
default.step) instead of being fixed for the whole brew, since both
change over a mash (malt going in, water boiling off).
Sud.derive_plant_params() takes them as arguments so it can be
recomputed per step; the demo re-applies the resulting M/C to both the
real plant and the controller's Smith-predictor model on every step
change via the new Pot.set_thermal_params()/
TempController.set_model_params().

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

README.md

@@ -129,10 +129,7 @@ environment (`$WORKON_HOME`/`$BREWPI_HOME`) on a Raspberry Pi-style deployment.
 ## Mash schedules
 
 Files under `sude/` describe a brew's mash schedule ("Sud"): `pot_mass`,
-`pot_material`, `grain_mass`, `water_mass` (used by `Sud.derive_plant_params()`
-to compute a lumped thermal mass/specific-heat pair for `Pot`'s `M`/`C`, e.g.
-in `scripts/demos/sud/demo_sud.py`, instead of hand-tuning them), and a
-`steps` list, each either:
+`pot_material` (fixed for the whole brew), and a `steps` list, each either:
 
 - a ramp — `"ramp": {"rate": ..., "temp": ...}` — ramp to `temp` at `rate`
   (°C/min), or
@@ -147,6 +144,16 @@ Both `ramp` and `hold` carry a `stirrer` block (`speed`, `interval_time`,
 the user with) to pause for confirmation once the step completes, e.g. to
 add malt or check gravity, instead of advancing immediately.
 
+Each step also has its own `grain_mass`/`water_mass` (defaulted like
+everything else from `default.step`), since both change over the course of
+a brew — e.g. malt going in partway through, or water boiling off. Pass a
+step's `grain_mass`/`water_mass` to `Sud.derive_plant_params()` (together
+with the brew-wide `pot_mass`/`pot_material`) to get that step's lumped
+`Pot` `M`/`C`; `scripts/demos/sud/demo_sud.py` recomputes and re-applies
+these (via `Pot.set_thermal_params()`/`TempController.set_model_params()`,
+on both the real plant and the controller's Smith-predictor model) every
+time the current step changes, instead of deriving them once at startup.
+
 The top-level `default.step` object gives every field above (including the
 nested `ramp`/`hold`/`stirrer` blocks) a default value; a step in `steps`
 only needs to specify the fields it overrides — anything it omits is filled