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/sud.py

@@ -33,15 +33,26 @@ def _merge_defaults(default, override):
 
 
 def _build_step(number, defaults, raw_step):
-	"""Fills in a schedule step with default.step's values. A step is a
-	ramp or a hold depending on which of those keys it specifies; the other
-	is left out rather than synthesized from defaults."""
+	"""Fills in a schedule step with default.step's values. 'ramp' is
+	always synthesized from defaults, even if raw_step doesn't specify
+	one of its own - every step ramps toward 'temperature' first, for as
+	long as the controller's own gap-tracking FSM says it needs to (see
+	Sud._advance()/temp_reached()), so its settings (e.g. 'rate') always
+	have to be available. 'hold' stays opt-in: only a step that
+	specifies it gets a hold-duration phase once the ramp is done.
+
+	'temperature' is deliberately *not* defaulted from default.step (every
+	sude/*.json's default.step.temperature is just inert template filler,
+	never a real shared target) - a step omitting it has no new target of
+	its own, so it's left None, telling SudTask not to push a new
+	theta_soll and just keep whatever the previous step left running."""
 	step = {'number': number}
-	for key in ('descr', 'user_message', 'user_wait_for_continue', 'grain_mass', 'water_mass', 'temperature'):
+	for key in ('descr', 'user_message', 'user_wait_for_continue', 'grain_mass', 'water_mass'):
 		step[key] = raw_step.get(key, defaults.get(key))
-	for key in ('ramp', 'hold'):
-		if key in raw_step:
-			step[key] = _merge_defaults(defaults.get(key, {}), raw_step[key])
+	step['temperature'] = raw_step.get('temperature')
+	step['ramp'] = _merge_defaults(defaults.get('ramp', {}), raw_step.get('ramp', {}))
+	if 'hold' in raw_step:
+		step['hold'] = _merge_defaults(defaults.get('hold', {}), raw_step['hold'])
 	return step
 
 
@@ -198,14 +209,12 @@ class Sud(AttributeChange):
 			return
 
 		next_step = self.schedule[self.index]
-		if 'ramp' in next_step:
-			self.state = SudState.RAMPING
-		else:
-			# "duration" is in minutes; hold_remaining (ticked by tick()'s
-			# simulated-seconds dt) is in seconds.
-			self.hold_remaining = next_step['hold'].get('duration', 0) * 60.0
-			self.state = SudState.HOLDING
-
+		# Every step ramps toward 'temperature' first - whether that takes
+		# any real time depends on the actual gap, which only the
+		# temperature controller's own FSM can tell (see temp_reached()'s
+		# caller, SudTask.on_process()). 'hold' only starts counting down
+		# once the controller reports the gap closed.
+		self.state = SudState.RAMPING
 		self.user_message = next_step.get('user_message')
 		self.step = next_step