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/pid/temp_controller_base.py

@@ -80,6 +80,13 @@ class TempControllerBase(APid):
 
 	def set_theta_soll(self, value):
 		self.theta_soll_set = value
+		# Recompute the FSM right away against the new target, rather than
+		# waiting for the next process() tick - otherwise self.state can
+		# still read HOLD from the previous target for up to one tick
+		# after a much-further-away one is pushed, which would make
+		# is_holding() report "reached" instantly instead of once the gap
+		# has actually closed.
+		self.process_fsm(self.theta_soll_set - self.theta_ist)
 
 	def get_theta_soll(self):
 		return self.theta_soll
@@ -87,6 +94,13 @@ class TempControllerBase(APid):
 	def get_theta_soll_set(self):
 		return self.theta_soll_set
 
+	def is_holding(self):
+		"""Whether the FSM currently considers theta_ist close enough to
+		theta_soll_set to no longer be actively heating/cooling toward
+		it - the single source of truth for "is a ramp toward the
+		current target done" (see tasks/sud.py's SudTask)."""
+		return self.state == States.HOLD
+
 	def set_heatrate_soll(self, value):
 		self.heatrate_soll_set = value