Bug: recording-rules list returns empty despite existing rule groups (same as #135)

[nikita-m-cx]

Summary

cx recording-rules list returns an empty result even when many recording
rule groups exist in the tenant. This is the same bug class as #135
(webhooks list / integrations list) — the list handler returns []
while get <id> works and the underlying API clearly has the data. Likely
the same root cause fixed for integrations in #146: the list handler isn't
parsing the real response shape.

Version

cx 0.1.10 (also reproduced on the prior version).

Steps to reproduce

$ cx recording-rules list -o json
Fetching recording rule groups...
[]

$ cx recording-rules list
Fetching recording rule groups...
[0]:

Expected

A list of the tenant's recording rule group sets.

Evidence the data exists

1. cx recording-rules get <set-id> resolves an individual set fine (all
   groups + rules returned):

   $ cx recording-rules get <set-id> -o json
   {
     "id": "<set-id>",
     "groups": [ { "name": "...", "interval": 60, "rules": [ ... ], ... }, ... ]
   }

2. Hitting the REST endpoint directly with the same OAuth bearer token
   the CLI uses returns thousands of rule group sets:

   $ curl -s -H "Authorization: Bearer <cli-oauth-token>" \
       https://api.<region>.coralogix.com/mgmt/openapi/3/v1/rule-group-sets \
       | jq '.sets | length'
   2280

   So the data is present and listable via the API; only the CLI list
   handler returns empty.

Impact

list is the natural way to discover rule-group-set IDs. With it returning
empty, there's no CLI-only way to enumerate recording rules — you must
already know each set ID to use get. This blocks scripting/automation and
discovery.

Likely fix

Same as #146 for integrations: parse the real list/Fetch response shape
({ "sets": [ ... ] }) in the recording-rules list handler. Compare with
the working recording-rules get path, which parses the set correctly.

Related: #135, #146.