Prevent summer/wintertime changeover from sending the snap range logic into a loop

[duxovni]

The logic in _get_snap_range breaks when the range is set to a 24-hour period that starts less than 12 hours after the the EST/EDT transition. For example, if t1 is 2025-03-09 06:00 EDT and t2 is 2025-03-10 06:00 EDT, then the unrounded t3 is 0.5 * (2025-03-08 18:00 EST + 2025-03-09 18:00 EDT) = 2025-03-09 06:30 EDT, which gets rounded up to 07:00. Then once the target range changes to 07:00, the snap range gets rounded up to 08:00, and so on until it hits 15:00 and the snap range logic works again.

I'm breaking the loop by adding a simple "if it ain't broke, don't fix it" check to _get_snap_range: If the current target range already has the correct length and alignment, then we don't attempt to do the possibly-broken math to recalculate it. Maybe there's a fancier way to adjust the calculations so they produce more consistent outputs, but this seemed like the simplest solution.

[almarklein]

Thanks!