WebChat v2 400 Bad Request during BYOC Trunk Metadata Injection for Digital Channels

Dealing with a very strange bug here with the WebChat v2 API integration when attempting to inject custom carrier failover metadata into the digital session context. Our environment manages fifteen BYOC trunks across APAC regions, and while the SIP registration and voice routing failover logic remains stable, the digital messaging pipeline is throwing intermittent HTTP 400 Bad Request errors. The issue specifically occurs when the Architect flow attempts to pass the carrier_failover_priority array via the /v2/conversations/webchat/messages endpoint during the initial session handshake. The payload structure mirrors our successful voice channel metadata injection, which includes a JSON object containing trunk_id, region_code, and failover_sequence. However, the Genesys Cloud response returns a validation error indicating that the metadata field exceeds the expected schema constraints for digital conversations, specifically citing a type_mismatch for the nested failover_sequence array. We are using the Genesys Cloud Web SDK version 2.1.4 and have verified that the JSON structure is valid against the standard RFC 8259 specification. The error does not occur when the failover_sequence is omitted, suggesting a strict validation rule within the digital channel API that differs from the telephony API. This discrepancy is causing our analytics reporting module to fail in capturing the correct trunk utilization metrics for digital sessions, as the metadata is dropped before the conversation is fully established. Has anyone encountered a similar schema validation issue when trying to unify metadata structures across voice and digital channels in a BYOC environment? We need to maintain consistent failover logic reporting across all communication types, but the current API limitations seem to enforce different metadata schemas for webchat compared to SIP trunks. Any insights on how to properly format the metadata object for the WebChat v2 endpoint to avoid these 400 errors would be greatly appreciated, especially given the strict timezone synchronization requirements for our APAC region reporting.