Odd sun-safety time behavior

Related to the comment I made in #218, but I noticed an odd behavior in the sun-safety checking when trying to investigate the sun-safety problem listed there. I found that the length of sun-safety can change depending on the start time even when not moving in az/el, which I do not think should be the case. For instance, when I calculate the sun-safety time starting at t0 while adding an increasing time offset:

offset = dt.timedelta(seconds=0)
while block0.t0 + offset <= block0.t1:
    t00 = get_traj_ok_time_socs(block0.az, block0.az, block0.alt, block0.alt,
                            block0.t0 + offset, sun_policy)
    offset = offset + dt.timedelta(seconds=60)
    print(f'{offset}: {t00}')

I get the following for the last few offsets:

1:35:00: 2025-08-09 13:23:35.554470+00:00
1:36:00: 2025-08-09 13:24:35.554470+00:00
1:37:00: 2025-08-09 13:23:35.554470+00:00
1:38:00: 2025-08-09 13:24:35.554470+00:00
1:39:00: 2025-08-09 13:23:35.554470+00:00
1:40:00: 2025-08-09 13:24:35.554470+00:00
1:41:00: 2025-08-09 13:23:35.554470+00:00
1:42:00: 2025-08-09 13:24:35.554470+00:00
1:43:00: 2025-08-09 12:51:35.554470+00:00
1:44:00: 2025-08-09 12:52:35.554470+00:00
1:45:00: 2025-08-09 12:53:35.554470+00:00

This is printing the offset time followed by the t0 + sun_time, which should be a constant number since as you increase the offset from t0, the sun_time should decrease by the same amount. I think the 1 minute shifts might make sense depending on the accuracy of the sampling, but I'm not sure why towards the end it thinks it is sun-safe for only a few minutes at the most, but if you check one minute before, it is okay for 30 mins longer. This happens for both the socs sun-safety checker and the built in scheduler one.

Implementation of get_traj_ok_time_socs

Config file:

platform: satp1

# yaml loads iso format automatically into datetimes
# t0: 2025-04-21T17:00:00+00:00
# t1: 2025-04-22T17:00:00+00:00

# yaml loads iso format automatically into datetimes
t0: 2025-08-08T16:00:00+00:00
t1: 2025-08-09T16:00:00+00:00
t0_state_file: None

cal_anchor_time: 2025-02-16T16:00:00+00:00

elevation: 60
min_hwp_el: 48

use_cal_file: True
use_wiregrid_file: False
#allow_partial_override: True
#az_branch_override: 180

# 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: 86400 # Relock every 24 hours
#home_at_end: True # Home: spin down HWP and go to (180,60)
bias_step_cadence: 1800

Start with get_traj_ok_time_socs in src/schedlib/policies/stages/build_op.py and reproduce the alternating results using the supplied loop and configuration. Compare its behavior with the built-in scheduler sun-safety checker. Done means equivalent fixed azimuth and elevation inputs produce a consistent sun-safe duration as the start time advances, aside from expected sampling precision.