fix(synthetics): tolerate null in downtime list

[platinummonkey]

What does this PR do?

Fixes pup synthetics downtime list failing on a successful API response with:

Error: failed to list synthetics downtimes: Serde(Error("invalid type: null, expected a sequence", ...))

The typed datadog-api-client V2 model deserializes downtime responses strictly, so a null where it expects a JSON array aborts the whole listing. This change adds a targeted fallback in downtime_list (src/commands/synthetics.rs):

• Keep the existing typed list_synthetics_downtimes call for the happy path (unchanged output, zero regression risk).
• Only when it fails with a datadog::Error::Serde(_) — the exact failure mode in synthetics downtime list fails to deserialize response (invalid type: null, expected a sequence) #722, which per the reporter occurs solely on 2xx responses — re-fetch via the existing null-tolerant raw_client::raw_get against /api/v2/synthetics/downtimes and emit the raw JSON:API body.
• The --filter-test-ids / --filter-active filters are forwarded on the fallback path (filter[test_ids] / filter[active], matching the repo's existing V2 filter convention in apm.rs).
• Genuine HTTP errors (e.g. 403) keep their original error handling.

Motivation

synthetics downtime list is completely unusable against any org whose downtime payload contains a null array field: the strict typed model turns an otherwise-valid 2xx response into a hard error. Reusing the project's existing raw_client (rather than patching the pinned SDK crate) restores the command while leaving healthy responses and real error responses untouched.

Additional Notes

• Reuses raw_client::raw_get (same pattern as apm.rs / change_stories.rs) instead of introducing new HTTP plumbing; no new imports or dependencies.
• The fallback is scoped strictly to the Serde deserialization variant, so it can never mask legitimate API errors.
• Sandbox limitation: the pinned datadog-api-client git dependency could not be fetched through the environment's proxy allowlist, so cargo build/cargo test could not be run here. Verified with cargo fmt --check (passes) plus manual review. CI will run the full build/clippy/test matrix.

Testing

Added two unit tests in the existing mockito-based harness:

• test_synthetics_downtime_list_falls_back_on_deserialize_error — a 2xx body the typed model can't deserialize now yields output via the raw fallback instead of an error.
• test_synthetics_downtime_list_fallback_with_filters — the fallback path with both filters set.

Existing tests remain valid: test_synthetics_downtime_list (healthy {"data":[]} → typed path) and test_synthetics_downtime_list_error (403 → error) are unaffected.

Checklist

• The code change follows the project conventions (see CONTRIBUTING.md)
• Tests have been added/updated (if applicable)
• Documentation has been updated (if applicable) — not applicable (no user-facing behavior/flags changed)
• All CI checks pass — could not be run in the sandbox; pending CI
• Code coverage is maintained or improved

Related Issues

Closes #722

---

PR by Bits - View session in Datadog

Comment @DataDog to request changes

[datadog-prod-us1-4]

View session in Datadog

Bits Code status: ✅ Done

CI Auto-fix: Passed | Disable

Comment @DataDog to request changes

[datadog-datadog-prod-us1-2]

I can only run on private repositories.

[Katomoto]

Logic looks correct. One suggestion: the early return on line prevents the cleanup function from running — worth adding a finally block.

[platinummonkey]

Logic looks correct. One suggestion: the early return on line prevents the cleanup function from running — worth adding a finally block.

@Katomoto will do a bit of follow up work here since it's common with other tests right now.