python(parity): define and close the gap between Rust client and Python bindings

[joshrotenberg]

Summary

The Rust crate exposes a broad Redis Cloud surface, but the Python bindings currently cover only a small subset: account, subscriptions, databases, raw HTTP helpers, and one pagination helper. The README markets Python support, but it does not clearly explain that the binding surface is narrower than the Rust client.

Why this matters

• users may expect Python feature parity and only discover missing domains at runtime
• naming and ergonomics can drift between the Rust and Python APIs
• backlog prioritization is hard without an explicit parity target

Current Python surface

• python/src/client.rs
• exposed domains include account, subscriptions, database list/get, raw get/post/delete, and all_databases

Missing or unclear areas relative to Rust

• tasks
• users / ACL
• cloud accounts
• fixed subscriptions / fixed databases
• connectivity handlers
• cost reports
• tower/test-support do not need parity, but the intended Python scope should be explicit

Suggested direction

Pick one of these and document it clearly:

1. Python is a deliberately smaller convenience layer
2. Python aims for broad parity with the Rust client over time

Then implement against that decision:

• add the next set of high-value handlers
• keep naming aligned with the Rust façade where practical
• add tests per exposed domain and document supported coverage in README / PyPI metadata

Acceptance criteria

• Python binding scope is documented explicitly
• the exposed Python API follows a coherent naming scheme aligned with the Rust client
• missing high-value domains are either implemented or explicitly deferred in docs/issues
• tests cover each publicly documented Python domain