fix: deliver request-adaptation failures through executeAsync's future

[OmarAlJarrah]

Summary

Both transports adapt the request synchronously at the top of executeAsync, before returning the CompletableFuture<Response>:

override fun executeAsync(request: Request): CompletableFuture<Response> {
    val okRequest = requestAdapter.adapt(request)   // may throw
    ...
}

A failure raised while adapting the request was therefore thrown on the caller's thread, not delivered through the returned future. A caller composing on the future never observes it:

transport.executeAsync(req)
    .exceptionally(t -> recover(t));   // never runs — the exception is thrown at the call site

Reachable adaptation failures today:

• JDK — IllegalArgumentException for a CONNECT request (the JDK client reserves CONNECT for tunnelling).
• OkHttp — IllegalArgumentException from Request.Builder.method for a method/body mismatch (e.g. a body on a GET).

Both methods already document that they "complete exceptionally with the transport failure on error", so the synchronous throw violated their own contract.

Change

executeAsync now catches an adaptation failure and returns a future completed exceptionally, so every post-call error flows through one channel. The synchronous execute path is unchanged — it keeps throwing, honouring its @Throws(IOException) contract.

The OkHttp module targets Java 8, where CompletableFuture.failedFuture (JDK 9+) is unavailable, so it completes a fresh future manually via a small failedFuture helper; the JDK module (Java 11) uses CompletableFuture.failedFuture.

Tests

• OkHttp: a body-bearing GET (which OkHttp rejects during adaptation) now yields a future that completes exceptionally with the IllegalArgumentException as its cause, instead of throwing synchronously.
• JDK: a CONNECT request (rejected during adaptation) likewise surfaces through the future.

Both tests fail against the pre-change code (the synchronous throw escapes before the future is returned) and pass after.

Internal change to the transport modules only — no public API change.

Closes #118