Envia um Pix outbound via Autra (POST /spi/v1/payments).

Suporta 4 modos de inicialização: KEY (chave), MANUAL (dados bancários),
QR_CODE_STATIC, QR_CODE_DYNAMIC.

Auto-enrichment para KEY (importante)

A Autra exige credit_party.bank (ISPB + agência + conta + tipo) e
end_to_end_id (com ISPB do destino, exigência BACEN) mesmo quando
initiation.type=KEY — mesmo o schema deles marcando bank como
required. Sem isso a Autra devolve 400 REQUIRED_ATTRIBUTE_MISSING.

Pra simplificar o app, o backend Autra faz o enrichment automaticamente:
quando o request chega com initiationType=KEY e SEM creditParty.bank,
o backend chama GET /spi/dict/v5/validate/{key}/account/{accountId}
internamente, monta o bank com os valores retornados (os campos
sensíveis vêm criptografados RSA pela Autra e passam crus — Autra decripta
do lado dela) e sobrescreve end_to_end_id pelo gerado pelo DICT.

Resultado: pra KEY basta enviar creditParty.key (+ amount + device

• PIN). Se o app passar creditParty.bank explicitamente, esse tem
  precedência e o backend pula o enrichment.

Outros pontos

• Assíncrono: Autra responde 202 e status final chega via webhook
  (pic_*). Polling on-demand disponível em GET /pix-payments/{id}.
• Device obrigatório: device.deviceId deve estar AUTHORIZED em
  banking_devices (BACEN 491). A Autra é responsável contratual pela
  autenticação local do pagador (biometria/PIN no app).
• PIN transacional: enviar no header X-Account-Pin (não no body).
• Idempotência: idempotencyKey (body ou header Idempotency-Key).
  Mesma key reenviada devolve o registro original.
• Coexistência: esta rota é Autra. A rota legacy
  POST /v1/banking/pix/transfers (Caradhras) continua funcionando.