fix(suppression-rules): unwrap alertSchedulerRule envelope in list response

[jmcminn56]

Context

cx alerts suppression-rules list renders a row for each rule but every field is null/empty (-o json gives [{"id":null,"name":null,...}], the text table shows a blank row). The rule exists and create works — same failure mode as the earlier integrations list (#146) / webhooks list (#162) bugs: a response-shape mismatch that serde silently swallows because every field on AlertSchedulerRule is Option.

Linked Issues

• Same class as Bug: webhooks list and integrations list return empty despite existing webhooks/integrations #135 (integrations/webhooks list) and Bug: recording-rules list returns empty despite existing rule groups (same as #135) #153 (recording-rules list)

Design

The live API (GET /mgmt/openapi/5/alerts/suppression-rules/v1, verified on us1, 2026-07-18) wraps each array element:

{
  "alertSchedulerRules": [
    { "alertSchedulerRule": { "id": "...", "name": "...", ... },
      "nextActiveTimeframes": [] }
  ],
  "nextPageToken": ""
}

GetBulkAlertSchedulerRuleResponse deserialized each element directly as AlertSchedulerRule, so every field missed. Following the #162 pattern: the Rust field alert_scheduler_rules: Vec<AlertSchedulerRule> is unchanged (no mod.rs changes) — a deserialize_with unwraps the envelope at the JSON boundary. An untagged enum accepts both the wrapped (live) and flat (legacy/fixture) shapes, so the existing flat unit fixture still parses.

Changes

• src/commands/suppression_rules/api.rs: envelope unwrap via ListedAlertSchedulerRule untagged enum + unwrap_rule_envelopes deserializer
• Regression test with the real live-API payload shape (incl. nextActiveTimeframes sibling and nextPageToken); existing flat-shape test kept as back-compat coverage

Testing

• cargo test suppression_rules::api::tests — 4 passed (new wrapped-shape regression test + existing 3)
• Full cargo test — green
• Manual against live us1 tenant: cargo run -- alerts suppression-rules list now renders the rule's real id/name/enabled/created (was a blank row); -o json returns populated fields

Risks & Rollout

Low — deserialization-only, list path only. If the API ever returns flat rule objects again, the Flat variant still parses them. Rollback is a revert.

Out of Scope / Follow-ups

• GET .../suppression-rules/v1/{id} returns {} from the API itself (verified via raw curl on us1) — run_get faithfully prints it, so suppression-rules get <id> shows nothing useful; that looks API-side, not CLI-side. Happy to file separately if useful.
• Bug: recording-rules list returns empty despite existing rule groups (same as #135) #153 (recording-rules list) — didn't touch here, but likely the same envelope pattern is worth checking.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bc1cd0d6c5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Surface the scheduler unique identifier

For the live wrapped shape, the payload contains both uniqueIdentifier and id, but this test now locks the CLI onto the inner id; run_list renders rule.id as the ID column while get/delete pass that value to /suppression-rules/v1/{alert_scheduler_rule_id}. The v5 docs describe that path parameter as the rule's unique identifier, so tenants that return separate version IDs here will show an ID users cannot reliably feed back into cx alerts suppression-rules get/delete; deserialize uniqueIdentifier and prefer it for the displayed/actionable ID.

Useful? React with 👍 / 👎.