State time not agreeing with block times

For this config:

platform: satp1

# yaml loads iso format automatically into datetimes
t0: 2025-04-18T16:00:00+00:00
t1: 2025-04-19T16:00:00+00:00
t0_state_file: None
#t0_state_file: satp1/state_files/state_2025-04-18T16:00:00+00:00.npy

elevation: 60
min_hwp_el: 48

# optional, only needed if running non-defaults
#hwp_override: False # True: forwards, False: backwards
az_motion_override: False # True: overwrite azspeed as set above, False: use
#azspeed written in the master schedule.
relock_cadence: 84400 #86400 # Relock every 24 hours
#home_at_end: True # Home: spin down HWP and go to (180,60)
bias_step_cadence: 1800
#no_cmb: True

cal_targets:
  - source: jupiter
    elevation: 48.0
    boresight: 0
    focus: 'ws1,ws0'
    allow_partial: True
    az_speed: 0.8
    az_accel: 1.0
    az_branch: 90
    source_direction: 'setting'
  - source: jupiter
    elevation: 48.0
    boresight: 0
    focus: 'ws6'
    allow_partial: True
    az_speed: 0.8
    az_accel: 1.0
    az_branch: 90
    source_direction: 'rising'

There is one block where the current state time is 4 minutes later than the start time of the block even after the fix of #230 which updates the wait commands:

# hwp already spinning with forward=False
run.wait_until('2025-04-19T08:27:30+00:00')
# scan duration = -1 day, 23:55:30
run.seq.scan(
    description='NW ... Happy Holy Saturday',
    stop_time='2025-04-19T08:42:00+00:00',
    width=40.0, az_drift=0,
    subtype='cmb', tag='2803edc9-413c-4052-9504-73d2ee752e23,271-311',
    min_duration=600,
)

Start by tracing the scheduler entry point that produces the shown run.wait_until and run.seq.scan commands for this configuration. Compare the generated state time with the block start and inspect how wait and scan durations are calculated. Done means the affected block's state time agrees with its block start while preserving the expected command timing.