docs: document Basic-only proxy auth across both transports

[OmarAlJarrah]

Problem

The proxy-authentication documentation contradicted itself across ProxyOptions and the two shipped transports:

• ProxyOptions told callers the JDK transport "negotiates Basic or Digest" with the proxy.
• The JDK transport's KDoc (and a runtime warning) steered Digest users to "use the OkHttp transport for Digest proxy auth."
• The OkHttp transport's KDoc stated it only ever emits Basic.

At most one of those could be right, and a reader following the docs was sent in a circle.

Reality

Both shipped transports authenticate the proxy with Basic only:

• The OkHttp proxyAuthenticator always responds with Credentials.basic(...) and a Proxy-Authorization: Basic … header. There is no Digest code path.
• The JDK transport installs a java.net.Authenticator on java.net.http.HttpClient. The client's built-in handling of a registered authenticator covers the Basic scheme only; it does not drive Digest proxy auth through that hook.

Change

Reconcile all three KDoc blocks and the two runtime warning strings:

• ProxyOptions now states that both transports do Basic-only proxy auth, and points Digest-proxy users at a caller-supplied client (a java.net.http.HttpClient / OkHttpClient with their own authenticator) passed through create(...).
• The JDK transport KDoc records the Basic-only limitation explicitly and drops the circular "use the OkHttp transport for Digest" steer. The challenge-handler warning now points at the BYO-client path.
• The OkHttp transport warning likewise points at a BYO OkHttpClient with a custom proxyAuthenticator instead of implying another shipped transport supports Digest.

A ProxyAuthenticator test pins that the JDK authenticator returns the raw credentials regardless of the advertised scheme, so the Basic-only behaviour is the JDK client's and a Digest-only proxy is not satisfied end-to-end.

No public API signatures change.

Closes #109