HttpRequest.url() logs spaces in path segments as literal plus signs

Description

HttpRequest.url() uses URLEncoder for both query components and path segments:

append(URLEncoder.encode(segment, "UTF-8"))

URLEncoder applies form/query encoding semantics, where a space becomes +. That is valid for the query-string usage in the same method, but a + in a URL path is a literal plus character rather than a space escape.

As a result:

HttpRequest.builder()
    .method(HttpMethod.GET)
    .baseUrl("https://api.example.com")
    .addPathSegment("user name")
    .build()
    .url()

currently returns:

https://api.example.com/user+name

The actual OkHttp transport does not use this string to construct requests. It calls HttpUrl.Builder.addPathSegment("user name"), which sends the path as user%20name. LoggingHttpClient, however, prints request.url(), so the SDK log can show a different request target from the URL that was actually sent.

Expected behavior

HttpRequest.url() should percent-encode spaces in path segments as %20, while preserving the current + encoding for spaces in query parameters.

Impact

This is an observability/debugging correctness issue. Logs produced by LoggingHttpClient can misrepresent path parameters containing spaces, making reproduced requests target a different resource.

Suggested fix

Keep the existing form encoding for query components, but normalize the encoded path-segment result from + to %20. A literal + remains safe because URLEncoder already represents it as %2B.

Start with the HttpRequest.url() entry point and inspect how URLEncoder is used for path segments versus query components. Compare its output with the HttpUrl.Builder path handling used by the actual transport and the URL printed by LoggingHttpClient. Done means path spaces appear as %20, query spaces retain + encoding, and literal plus signs remain correctly encoded.