BatchResult.error is a bare string, so batch failures lose kind, conclusion and attempts #139

On the 1.0 branch (#128, as of 3e1629e), a failed request() raises TransportError carrying kind, tls_failure, retryable, conclusion and attempts. A failed request in request_batch_stream() gets none of that. BatchResult.error is still Optional[str].

The Rust side has the full ClientError (BatchResult.result in src/batch.rs:11), and the Python conversion throws it away, keeping only the message (to_py_batch_result in src/python.rs:918: Err(e) => (None, Some(e.message))).

This is the same loss #116 describes for request(), one layer over. Batch callers still have to substring-match the message to tell a timeout from a refused connection from a TLS failure, and a batch request that ends unreachable or needs_legacy_tls can't be told apart from any other failure.

BBOT's http module, which makes most of a scan's target requests, goes through the batch API, so it is the caller that most needs this.

Suggested fix: expose the same detail on BatchResult that TransportError carries, for example an error_kind, tls_failure, retryable, conclusion and attempts alongside error, or a transport_error attribute holding the TransportError itself. Keeping error as the message string avoids breaking existing callers.