Fill the post-confirm forecast gap with the real setpoint, not a mid-ramp snapshot

_continue_forecast_after_confirm()'s bridge was repeating forecast_theta[-1]
to cover the real-world wait, but that's whatever value the simulation
happened to log the instant WAIT_USER tripped - often still mid-ramp, not the
step's actual hold target. The real controller stays enabled and actively
holding throughout WAIT_USER, so capture its setpoint (tc.get_theta_soll_set())
in recv() before calling Sud.confirm() - confirming synchronously pushes the
next step's own target onto it - and use that to fill the gap instead.

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

README.md

@@ -309,8 +309,16 @@ looks up the relevant `confirm_points` entry, truncates the forecast right
 back to that point, and splices in a freshly anchored simulation of the
 remaining steps - anchored at the real elapsed time and real current
 temperature, so an actual delay shows up honestly as a gap in the timeline
-rather than as the assumed zero. The corrected forecast is sent in full
-each time, so the GUI's `SudForecastPlot.show_forecast()` simply redraws
+rather than as the assumed zero. That gap is filled at the real
+controller's setpoint at the moment of confirmation (`recv()` captures
+`tc.get_theta_soll_set()` *before* calling `Sud.confirm()`, since confirming
+synchronously pushes the next step's own target onto it) rather than
+whatever value the forecast happened to log the instant `WAIT_USER`
+tripped - the controller stays enabled and actively holding throughout
+`WAIT_USER`, so the setpoint is what it was actually converging toward
+during the wait, not a possibly-still-mid-ramp snapshot. The corrected
+forecast is sent in full each time, so the GUI's `SudForecastPlot.
+show_forecast()` simply redraws
 the dashed line outright rather than patching it up itself.
 
 Comparing the two lines: real-world divergence from the forecast - more