Does anyone understand why the recording_id in the bulk export manifest does not match the conversation_id returned by the GET /api/v2/recordings/{recordingId} endpoint for SIP trunked calls? We are processing a legal discovery request on EU1 and noticing that while digital channel recordings (WebRTC, Messaging) map correctly via the conversation_id field, SIP recordings lack this linkage in the initial export job results. The bulk export job completes successfully with status COMPLETED, but cross-referencing the files against our audit trail shows a 12% mismatch in metadata fields. Specifically, the recording_url points to a valid S3 bucket object, yet the associated callflow_id is null for these specific SIP segments. This breaks our chain of custody verification script which relies on deterministic ID mapping. We are using the standard recording:admin scope and have verified that the SIP trunk configuration has recording enabled at both the trunk and application level. Is there a known delay in metadata propagation for SIP recordings compared to digital channels, or is this a configuration issue within the Architect flow where the recording settings are applied?