Meeting QoS participants endpoint: user_qos backfills after a delay for the same date_time entry (live=true)

Endpoint: GET /metrics/meetings/{meetingId}/participants/qos

Observation: For the same participant and the same date_time bucket in participants.user_qos[], the live=true response appears to backfill cpu_usage on a subsequent call rather than returning it immediately.

Steps to reproduce:

1. Call the endpoint with live=true for an active meeting.
2. Look at the last element in user_qos[] (the most recent date_time entry).
3. On the first call, cpu_usage is returned as an empty object {}.
4. Call the endpoint again shortly after, with identical parameters.
5. The same date_time entry now returns populated cpu_usage fields (zoom_min_cpu_usage, zoom_avg_cpu_usage, zoom_max_cpu_usage, system_max_cpu_usage).

Question: Is this expected behavior — i.e., does user_qos for the latest date_time bucket lag behind the rest of the QoS metrics and get backfilled on a later poll? If so, is there a reliable signal (e.g., a flag, a minimum polling delay, or a separate "finalized" timestamp) we can use to know when the latest bucket's cpu_usage is safe to read, rather than polling repeatedly and diffing?

This matters for anyone polling live=true on a fixed interval and reading the last element as "current" — without knowing this lag exists, cpu_usage for the most recent sample will silently look empty/missing even though it's just not populated yet.