Since I did not touch the system, I would think it supports the fact that this is on their end
That would actually lead me to the opposite in this case.
I have no doubt the local rules are failing at the DST switch due to some interaction with the panel based on how the schedule is saved from the back-end. I have been giving info to ADC and working with support regarding this issue.
However, the back-end does not send commands to turn on lights for schedules, it does not process the action of scheduled changes - rules are created in Alarm.com, sent to the panel, saved in the module memory, and run locally.
All schedules failing at once indicates a problem with the schedule, how it is saved, or how it interacts with the panel. One schedule failing intermittently suggests issues locally.
When you reported schedules had failed, we sent commands to re-save all of your schedules, rebuild the rules, which clears previous saved schedules and replaces them.
Since most schedules started working, one that did not may indicate that it simply did not get saved properly. Rules were sent again.
You reported it did not work again, making me think that locally, there is an intermittent issue.
If it then worked without further intervention, it reinforces that conclusion. Since that device is not providing identical product info to the same model of switch on your account, I would suggest trying to re-enroll to see if that improves function.
Enrolling from too far of a distance can negatively affect performance down the line. Also, if you have added any devices since enrolling the switches and have not run a network rediscovery, that may also cause issues with certain routing commands.
The best troubleshooting step at this time would be to re-enroll that switch close to the panel, run a network rediscovery, then recreate the schedule and then test reliability.