Consul requests to KV store uses urlencoding

I use consul for externalized configuration. Recently playing aroung with spring boot 4.0.0-RC1 I noticed, that http requests to consul KV store uses urlencoding of key part in path. Instead of usual GET /v1/kv/config/application/?recurse it emits GET /v1/kv/config%2Fapplication%2F?recurse:

GET /v1/kv/config%2Fapplication%2F?recurse HTTP/1.1
Connection: Upgrade, HTTP2-Settings
Host: 127.0.0.1:8500
HTTP2-Settings: AAEAAEAAAAIAAAAAAAMAAAAAAAQBAAAAAAUAAEAAAAYABgAA
Upgrade: h2c
User-Agent: Java-http-client/25.0.1
Accept-Encoding: gzip
Accept-Encoding: deflate
X-Consul-Token: <hidden>

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: application/json
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
X-Consul-Index: 58350324
X-Consul-Knownleader: true
X-Consul-Lastcontact: 0
X-Consul-Query-Backend: blocking-query
Date: Mon, 27 Oct 2025 14:07:36 GMT
Content-Length: 1772

[{"LockIndex":0,"Key":"config/application/data",...snipped

Currently this works, but I'm not sure that this non standard requests will work on future versions of consul. Consul http api docs have nothing about urlencoding KV paths.

This change introduced by new implementation of consul client:

https://github.com/spring-cloud/spring-cloud-consul/blob/68fe9e3ebf9969e61db70e61bb399f4ee4df8b75/spring-cloud-consul-core/src/main/java/org/springframework/cloud/consul/ConsulClient.java#L65-L67

Start with ConsulClient.java at the linked lines 65–67 and compare its request construction with the Consul KV example in the issue. Confirm the expected path behavior against the Consul HTTP API documentation; done means KV requests preserve the documented path form without unwanted URL encoding.