Make Sud steps ramp based on the actual temperature gap, not a 'ramp' key

Previously, whether a schedule step ramped at all was decided purely by
the presence of a 'ramp' key (components/sud.py's _advance()) - a
hold-only step jumped straight into its hold countdown, assuming the
plant was already at temperature. Now every step ramps toward
'temperature' first, for as long as the controller's own gap-tracking
FSM (TempControllerBase, already distinguishing HEAT/COOL/HOLD) says
the gap actually warrants it - via the new is_holding() (on APid and
TempControllerBase), which replaces a separate, redundant
TEMP_REACHED_TOLERANCE constant duplicated across tasks/sud.py,
components/sud_forecast.py, and scripts/demos/sud/demo_sud.py.

set_theta_soll() now recomputes the FSM eagerly so is_holding() can't
read stale HOLD for a tick after a much-further-away target is pushed.

components/sud.py's _build_step() always synthesizes a 'ramp' block
from default.step.ramp (so 'rate' is always available), but leaves
'temperature' undefaulted - every real sude/*.json's
default.step.temperature is inert template filler, and defaulting it
would send hold-only steps chasing 0 degrees. SudTask/
SudForecastEstimator/the demo only push a new theta_soll/heatrate_soll
when a step actually specifies its own temperature; otherwise the
controller keeps whatever the previous step left running.

Also fixes a related crash this surfaced: SudTask.remaining_schedule()'s
synthetic mid-hold step dropped 'ramp' to signal "don't re-ramp" - now
that every step always carries a 'ramp' dict, dropping it left 'rate'
missing the moment the synthetic step was re-resolved by
SudForecastEstimator. Drops 'temperature' instead, which is what
actually signals "no new target" under the new model.

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

components/TODO.md

@@ -2,21 +2,31 @@
 
 Confirmed spec for a `Sud` schedule step's internal phase order
 (`components/sud.py`), from a design discussion clarifying how `ramp`/
-`hold`/user-confirm interact.
+`hold`/user-confirm interact, since implemented (gap-based ramping).
 
 ## Phase order
 
-`ramp` -> `hold` -> user-confirm. Each step independently opts into
-`ramp` and/or `hold` by including that key (`_build_step()`,
-`sud.py:35-45`); the other phase is skipped entirely if its key is
-absent. The `'ramp'` key's presence is the *only* trigger for ramping
-(`_advance()`, `sud.py:192-210`) - there is no diff-based decision
-(`T_actual` vs. `T_target`) anywhere that decides whether to ramp, and
-no internal setpoint-trajectory limiter in the temperature controller
-(`set_theta_soll()` is an instant, unconditional assignment,
-`components/pid/temp_controller_base.py:81-82`). The `ramp` key both
-gates ramping *and* carries its settings (`rate`); it does not merely
-override settings on top of an always-on ramp.
+`ramp` -> `hold` -> user-confirm. Every step ramps toward `temperature`
+first - this is *not* gated by whether the step has its own `ramp` block
+(`_build_step()` always synthesizes one from `default.step.ramp`,
+`sud.py:35-52`); `_advance()` (`sud.py:192-204`) always enters `RAMPING`.
+How long that actually takes depends on the real gap, decided by the
+temperature controller's own gap-tracking FSM
+(`TempControllerBase.is_holding()`, `components/pid/temp_controller_base.py`)
+rather than any fixed tolerance - `SudTask.on_process()`
+(`tasks/sud.py:200-203`) calls `sud.temp_reached()` once `tc.is_holding()`
+is true. `set_theta_soll()` recomputes the FSM eagerly
+(`temp_controller_base.py:81-89`) so `is_holding()` can't read one tick
+stale after a new target is pushed.
+
+`temperature` is the one field deliberately *not* defaulted from
+`default.step` (`sud.py:52`) - every `sude/*.json`'s
+`default.step.temperature` is inert template filler, never a real shared
+target. A step omitting it has no new target of its own: `SudTask`/
+`SudForecastEstimator`/the demo driver all skip pushing `set_theta_soll`
+in that case (`step['temperature'] is not None` guard), so the controller
+just keeps whatever the previous step left running and the ramp resolves
+immediately. `hold` stays opt-in, gated by raw presence as before.
 
 ## Duration `0`
 
@@ -42,17 +52,10 @@ message": `user_message` (display text) and `user_wait_for_continue`
 (the actual block) are independent fields - a step can show a message
 without blocking, or block silently.
 
-## Open items
+## Resolved
 
-- [ ] **Pure-hold steps never (re-)set the controller's target
-  temperature.** For a step with only `hold` (no `ramp`),
-  `tasks/sud.py`'s `on_step_changed` never calls `tc.set_theta_soll()`
-  - the guard at line 73 requires `ramp is not None`. The
-  controller's target temperature for a pure-hold step is whatever
-  was left from the previous step's ramp; there's no explicit
-  fallback to the hold step's own `temperature` field. `README.md`
-  (Mash schedules section) documents this as designed behavior
-  ("`SudTask` drives ... `theta_soll`/`heatrate_soll` from ramp
-  steps ... counts down hold steps' duration"), so it's intentional,
-  not a bug - but it means a schedule can't express a temperature
-  jump straight into a hold without a `ramp` block.
+- [x] **Pure-hold steps never (re-)set the controller's target
+  temperature.** Moot now that ramping isn't gated by the `ramp` key:
+  `SudTask.on_step_changed` pushes `set_theta_soll`/`set_heatrate_soll`
+  for *any* step that specifies its own `temperature`, not just ones
+  with an explicit `ramp` block.