Immediately prior to the lockloss (at 22:59:42.89 to be precise), the SQZ_MANAGER guardian reported the notifications "SQZ ASC AS42 not on?? Please RESET_SQZ_ASC"
and "FC-IR UNLOCKED!"
ISC_LOCK jumped to LOCKLOSS at 22:59:43.58, so I suspect the filter cavity unlocking had something to do with this lockloss. However, I'm not sure if we've seen a lockloss from just the FC unlocking in the past, so I hesitate to say this was the definitive cause or just a case of guardian loop timing showing a red herring.
This might be the same as alog 71659, where ISC_LOCK was just slower than SQZ in detecting the lockloss. If this is the case it could be that ISC_LOCK's lockloss thresholds need updating.
Comparing the 2kHz ASC-AS_A channel against SQZ-LO_SERVO_ERR_OUT, AS_A sees a bump before the hit to SQZ-LO_SERVO, so the previously mentioned guardian log messages indeed had me misled. ISC_LOCK doesn't jump to LOCKLOSS until almost a full second after this.