Get connection status

Provisions a new WhatsApp connection inside this grant. The core starts a QR pairing session and returns an initial QR code. Render `qr` (a data-URI PNG) and poll `GET /connections/{id}` every 3–5 s until `status` is `"connected"`, re-rendering the `qr` from every response. **WhatsApp rotates the pairing code roughly every 20 seconds**, so the `qr` in this create response is stale within seconds: a QR left on screen simply never pairs, and nothing surfaces an error to explain why. Do not cache it, and do not treat the create response as the pairing code. **With an API key there is no bootstrap step:** a key is issued against your workspace directly, so this endpoint creates the FIRST connection as readily as the tenth — nothing has to be clicked in a portal UI first. (An OAuth grant, by contrast, can only be issued over connections that already exist, so an OAuth-only integration still needs one connection to exist before it can create more. That is the reason to start with a key.) Standalone workspaces only — a Bitrix24-owned portal is rejected with 403 `forbidden_portal_kind`. Check `GET /account` first: creating past your slot quota leaves the new connection without an active licence. Connections created here are QR/WAPP (`provider: qr`); WABA numbers are onboarded through Meta embedded signup, not this endpoint. **Idempotency (optional).** Creating a connection provisions a WhatsApp session and consumes a paid SLOT at pairing time, so an HTTP client that times out and retries would otherwise create a SECOND connection — and you would silently pay for two slots for one customer. Send an optional `Idempotency-Key` header to make the retry safe: within 24 h the same key + the same body returns the SAME connection with **200** and `Idempotency-Replayed: true` instead of provisioning again; the same key with a DIFFERENT body is rejected with 400 `idempotency_key_reuse`; and while the first request is still in flight the retry gets 409 `idempotency_in_progress` with `Retry-After: 1`. Generate ONE key per customer-onboarding ATTEMPT (a fresh UUID minted right before the call, reused only by that call's retries) — never one per process, per API key, per day, or a constant. Omit the header and behaviour is exactly as before. This is the only endpoint that supports it.