Can anyone clarify the expected latency window for sip_trunk_failover_events to appear in the telephony_metrics dashboard after a carrier timeout? We are managing 15 BYOC trunks across APAC regions, and recently noticed a 45-second delay between a SIP 408 Request Timeout on our primary carrier and the corresponding event logging in Genesys Cloud. The environment uses architect_flow_id: af_9928374 with strict failover logic set to immediate on trunk group tg_byoc_apac_01. When querying the GET /api/v2/analytics/telephony/queues/summary endpoint via the SDK v3.5.2, the total_failovers count remains zero for nearly a minute post-event, despite the call successfully routing to the secondary trunk. This lag impacts our real-time carrier performance SLA reporting, which relies on accurate carrier_health_score calculations. Is this a known synchronization delay with the SIP registration state refresh, or should we be polling a different endpoint like GET /api/v2/architect/flows to capture the routing decision timestamp directly? The carrier logs confirm the timeout at 14:02:15 SGT, but Genesys only reflects the state change at 14:03:00 SGT.