Expõe a mensagem de erro da API quando a requisição falha no multi_format_api

[gabrielbressan-tfy]

Contexto

Quando uma requisição HTTP do handler multi_format_api falha, o erro propagado continha apenas a linha de status do requests (ex.: 400 Client Error: Bad Request for url: ...). O corpo da resposta — onde as APIs normalmente explicam o motivo real — era descartado.

Isso obrigava a adivinhar a causa. Exemplo real: a API da massive.com responde {"status":"ERROR","error":"API Key was not provided"} (e mensagens análogas para parâmetros inválidos), mas nada disso chegava ao usuário; só aparecia o 400/401 genérico.

O que foi implementado

Um helper que extrai a mensagem de erro do corpo da resposta que falhou e a anexa tanto ao erro levantado quanto ao log:

• se o corpo for JSON, usa error / message / detail;
• caso contrário, inclui o corpo bruto truncado (500 chars).

Sem corpo disponível, o comportamento é o de antes.

Arquitetura e decisões

• Mudança pequena e localizada no tratamento de exceção do fetch; não altera o caminho de sucesso nem o parsing.
• Defensivo: tolera respostas sem corpo, corpo não-JSON e objetos de resposta que possam falhar ao ler .text.

Pontos de atenção para review

• Validado contra a resposta real de erro da massive.com: a mensagem passa a incluir | API error: API Key was not provided em vez de só a linha de status.
• Cuidado usual: o corpo pode conter dados sensíveis; por isso é truncado. Se algum endpoint retornar segredos no corpo de erro, convém revisar o truncamento.

🤖 Generated with Claude Code