CommunicationsResource uses prefix-style method names (get_rfq/get_quote) inconsistent with every other resource #348

Problem

The rest of the SDK uses client.<resource>.<verb>(id, ...) — client.orders.get(...), client.markets.get(...), client.events.get(...). CommunicationsResource re-encodes the noun in the method name: get_id, list_rfqs, get_rfq, create_rfq, delete_rfq, get_quote, create_quote, delete_quote, accept_quote, confirm_quote. Two costs: autocomplete spills both get_rfq and get_quote into the namespace, and the precedent makes any future sub-noun (e.g. negotiations) worse.

The RFQ-vs-Quote disambiguation can be done with sub-namespaces (client.communications.rfqs.get(...)) the same way the OpenAPI tag structure already groups them.

Evidence

• kalshi/resources/communications.py:208-332 — prefix-style names

def get_id(self, ...) -> GetCommunicationsIDResponse:
def list_rfqs(self, ...) -> Page[RFQ]:
def get_rfq(self, rfq_id: str, ...) -> GetRFQResponse:
def create_rfq(self, ...) -> CreateRFQResponse:
def delete_rfq(self, rfq_id: str, ...) -> None:

• kalshi/resources/markets.py:297, events.py:174, orders.py:423 — all use the bare verb get(id, ...).

Suggested fix

Introduce two sub-resources client.communications.rfqs and client.communications.quotes, each exposing list/list_all/get/create/delete (and accept/confirm on quotes), matching the OpenAPI v3.18.0 tag structure. Deprecate the flat names for one release with DeprecationWarning forwarders. Update docs/resources/communications.md to document the new shape. Treat this as breaking under the existing v2 deprecation policy.

Source

Round-3 independent audit (reviewer: resources_api).