[Mohith26]

The KV store client builds request paths with base_url.join(&format!("lists/{key}/contains/{item}")), so keys and list items are parsed as URL syntax instead of being sent as values:

• list_contains_item("my-list", "https://example.com/a?b=1#top") requests /lists/my-list/contains/https:/example.com/a with query b=1, and the #top part is dropped.
• get_set("user:1/profile") requests /sets/user:1/profile.
• delete_list_item("my-list", "../../sets/x") sends DELETE /sets/x, a different endpoint.

This change adds a small url(&[segments]) helper on ResolvedKvStoreConfig that appends segments with path_segments_mut(), the same approach admin::transactions uses for get_transaction, and uses it for every KV endpoint that takes a key or item. Plain keys like my-key or user:1 produce exactly the same URLs as before. One behavior note: a caller who was already percent-encoding keys themselves would now get them encoded twice.

Testing:

• Added three wiremock tests (get_set_key_is_one_encoded_path_segment, list_contains_item_encodes_key_and_item, delete_list_item_cannot_escape_the_list) that expect the encoded path. All three fail on main and pass with this change.
• cargo test -p quicknode-sdk --lib: 289 passed. cargo fmt --all -- --check and cargo clippy -p quicknode-sdk --lib --tests -- -D warnings are clean. I didn't build the Python/Node/Ruby bindings locally; the public method signatures are unchanged.
• I don't have a KV Store account, so I haven't checked this against the live API. It assumes the API decodes percent-encoded path segments, as standard HTTP routers do.

I used an AI assistant while working on this, and reviewed and tested the change myself.