L. Dartez, T. Sanchez, J. Driggers, M. Pirello, J. Rollins, J. Betzwieser

The H1 calibration has been updated to account for the additional 15.2us delay due to the new LIGO DAC card used in the ETMX L3 path.

There was a bit of confusion and imperfect communication over how the new DACs were implemented that contributed to some locking troubles after the maintenance period. 
- First, the DACs were only installed for ETMX-L3 for now. With conflicting emails and alogs I walkedin thinking all 3 stages had their DACs swapped.
- The gains that I adjusted in the COILOUTF and ESDOUTF filter banks were not used. On L1 and L2 this is because there was no DAC swap. On L3 it's because the new DACs have a built-in gain that serves the same purpose as the ones I adjusted. as such, the '32bit DAC' FMs are ignored and can be purged.

Updating the calibration pipeline for this change required steps that are outside of the anticipated. 
Our last exported report, 20240330T211519Z, represents the state of the DARM model that is used to inform the front end and the GDS pipeline. I copied this report into 20240917T222803Z (this time stamp is not associated with any measurement files; i made it up as the time at which I was doing the copying) and updated the pydarm_H1.ini to include an additional 15.2 us delay in the unknown actuation delay parameter for the X arm, bringing the total 'unknown' actuation delay to 30.2us. I then updated the id file to reflect the new report id and regenerated the new report using  pydarm report --regen 20240917T222803Z (I should have used --skip-mcmc also but that's ok). Then I had to fix the id file _again_ after the generation before committing and uploading the report to ldas. 

Once the report was committed, I exported it to the front end. The front end value changes are all on the order of a percent or two due to rerunning the MCMC during the generation. Note to pydarm devs: I had to mark this report as 'valid' in order to get pydarm to export it. But I didn't want to mark it as valid since we won't want this report to be considered as a unique measurement in the uncertainty budget. We'll need to remove the valid tag before preparing the unc budget for O4b.

There was some trouble getting GDS restarted but Jamie and Jonathan jumped in to help with that. It was just an auth issue.