Soprano: switch to the omnimsg endpoint contract

[Hou (SciencePotato)]

Switches the Soprano adapter to the omnimsg contract from Soprano's CYOT integration guide, in all three language implementations.

What changed

• One endpoint for every channel: POST {EPP_PROVIDER_ENDPOINT}/messages/omnimsg replaces /messages/sms and /messages/voice.
• Body follows the documented contract: text, destination (E.164 with the leading + stripped), messageTypes: ["sms"|"voice"], correlationId, shutterMode.
• Removed: messageType, clientReference, the voice.text2voice block, and the endpoints/source sender fields — omnimsg renders the voice TTS from the same text and takes the sender from the account provisioning. SOPRANO_SOURCE_TYPE, SOPRANO_VOICE_LANGUAGE and SOPRANO_VOICE_GENDER are no longer read.
• Added optional SOPRANO_SHUTTER_MODE app setting — sends shutterMode: true so Soprano processes the request but delivers nothing, for connectivity and credential testing. This is distinct from the pipeline's own evaluation-mode shutter, which still returns before any HTTP call is made.
• FILTERED is mapped to Fail — see below.
• parseResponse is unchanged; it already handled {id, destination, status}.

Verified end to end against Soprano QA4

Both channels confirmed working on the live QA4 environment, against a destination Soprano confirmed is routable:

Channel	Provider response	Pipeline result
sms	201 — {"id":400004307033,"destination":"61434024858","status":"ENROUTE"}	200 / Continue / accepted
voice	201 — {"id":400004307034,…,"status":"ENROUTE"}	200 / Continue / accepted

Response body from the pipeline:

{
  "status": "accepted",
  "outcome": "Continue",
  "provider": "soprano",
  "channel": "sms",
  "providerMessageId": "400004307033",
  "providerStatus": "ENROUTE",
  "requestId": "req-..."
}

Why FILTERED is mapped to Fail

Destinations outside the account's routing come back as 201 with status: "FILTERED" rather than an error — accepted, then silently dropped, with no reason field. Observed on US destinations and on one AU number, identically on the previous /messages/sms path and with or without a sender field, so it is a routing decision rather than a payload problem. Mapping it explicitly to Fail documents the behaviour instead of relying on the fail-closed default.

For contrast, a genuinely malformed request is reported properly: an invalid destination returns 400 with errorCode 400102 and Invalid destination address, which flows through to providerStatusDescription.

Open question for Soprano

Does FILTERED ever indicate a policy block (blocklisted MSISDN) in production? If so it may belong on Block/403 rather than Fail/502.

Note: Entra ID v2.0 bearer auth is not wired end-to-end — there is no outbound token acquisition, so oauth2 mode fails closed and QA4 runs on the X-MEMS-* headers.

Tests

javascript 37 passed, python 24 passed, dotnet 23 passed.