Connect errors lose their cause, so cert failures are retried and messages say only "client error (Connect)" #116

Problem

When a pooled request fails while connecting, dispatch_request in src/client/hyper.rs builds the error from hyper-util's top-level error only:

let msg = format!("request failed: {}", e);
let err_str = e.to_string().to_lowercase();
if err_str.contains("ssl") || err_str.contains("tls") || err_str.contains("certificate") {
    ClientError::tls(msg)
} else {
    ClientError::connection(msg)
}

hyper-util's Display for its client error is just client error ({kind:?}). The real cause (certificate verify failed, connection refused, proxy rejected CONNECT, and so on) is in source(), which is never read. Two things follow:

1. The message doesn't say why. Every connect failure reads request failed: client error (Connect), whether the cert was bad, the port was closed, or a proxy refused the tunnel.
2. TLS and certificate failures are retried. The check for "ssl", "tls" or "certificate" never matches, so they're classified as ErrorKind::Connection, which is_retryable retries. With the default retries=1, every host with a bad cert costs an extra attempt plus at least retry_wait_min_ms of backoff.

This happens on direct requests too, not just through a proxy.

Reproduction

verify_certs=True against the self-signed server in tests/tls_integration.rs (test_verify_certs_true_rejects_self_signed) fails with:

ClientError { message: "request failed: client error (Connect)", kind: Connection }

The test only asserts is_err(), so it passes anyway.

Proposed Solution

Walk the error's source() chain, append the causes to the message, and run the TLS check against the full chain, so a cert failure is ErrorKind::Tls and isn't retried. Tighten test_verify_certs_true_rejects_self_signed to assert ErrorKind::Tls.

The error text gets longer as a result, so anything matching on the exact string client error (Connect) would need to change.