Generalize Sud forecast reanchoring to every step boundary

Reanchoring used to only happen when a user confirmed a WAIT_USER
step, so anything the schedule advanced through on its own (a ramp
reaching target, a hold timing out) left the forecast showing a
stale, increasingly wrong prediction once reality diverged from it.
_reanchor_forecast() now fires from on_step_changed() on every real
transition, splicing in a fresh simulation anchored at the real
current temperature/elapsed time instead.

Also fixes two bugs surfaced while testing that change:
- estimate()'s early-return for an empty/not-yet-loaded schedule still
  returned the old 4-tuple shape, crashing every connection before a
  Sud was ever Loaded.
- send_forecast() and _reanchor_forecast() can run concurrently (e.g.
  a fresh Start triggers both at once), and whichever resumed second
  after its own worker-thread simulation would blindly splice its tail
  onto whatever the other had already written, producing a spurious
  connecting line across the plot. Both now carry a generation counter
  and discard their result if a newer call has since committed.

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

tasks/sud_log.py

@@ -33,8 +33,8 @@ class SudLogTask(ATask):
 	is of no use before the run is over anyway. The forecast file is
 	written from SudTask.forecast_t/forecast_theta as they stand at
 	that point - the *final*, most-corrected version (see tasks/sud.py's
-	SudTask._continue_forecast_after_confirm()), not the optimistic
-	guess computed back at Load.
+	SudTask._reanchor_forecast()), not the optimistic guess computed
+	back at Load.
 
 	Samples are taken once per interval regardless of Sud.state
 	(RAMPING/HOLDING/WAIT_USER/PAUSED all keep recording, mirroring