Suportar o Guzzle 8: a RetryPolicy depende de uma API que ele removeu #121

O Dependabot propôs o Guzzle 8.3 no #118 e o CI reprovou com:

Call to undefined method GuzzleHttp\Exception\ConnectException::getHandlerContext()
  em RetryPolicy::neverSent()

No Guzzle 8 a ConnectException é uma classe vazia; o acessor saiu. O #118 foi fechado e o #120 põe regra para o Dependabot não propor major do Guzzle de novo — então o suporte à 8 fica aqui, para não se perder.

O que precisa ser feito

1. Achar como obter o errno do cURL na API nova. É o que a RetryPolicy::neverSent() usa para separar 5/6/7/35 (nada saiu da máquina) de 28 com conexão estabelecida (o corpo pode ter sido processado) e de 52 (chegou e não respondeu). Sem essa informação a política não pode repetir POST nenhum, nem com chave de idempotência — seria cobrar duas vezes no timeout. Se o Guzzle 8 não expõe o errno, a saída é um handler próprio ou ler o curl_getinfo de outro jeito; o fallback honesto, se nada disso der, é tratar toda falha de transporte como "foi enviada".
2. Reconfirmar o .p12 no mTLS. O CLAUDE.md registra que a 7.3 é a primeira que entrega .p12 ao cURL pela extensão, e a API Pix da Efí depende disso. Precisa de teste com certificado real no sandbox, não só suíte verde.
3. Refazer os testes da política (tests/Unit/Http/RetryPolicyTest.php): os sete que falharam no chore(deps): bump guzzlehttp/guzzle from 7.15.5 to 8.3.0 #118 são justamente os que provam o comportamento seguro, então eles são o critério de pronto, não um detalhe.
4. Decidir se a lib passa a aceitar ^7.3 || ^8.0 ou se troca de major — e, se trocar, se o piso de PHP sobe junto.

Pronto quando

Os sete testes de neverSent() passam nas duas majors do Guzzle, a matriz do CI cobre as duas, e o caminho do mTLS foi exercitado com certificado de verdade.