fix(zhipu): read the quota response when it has no data envelope - #6479

Refs #6402.

What happens

The GLM Coding Plan card renders no tiers at all for some accounts, while the request itself succeeds — pointing a custom extractor script at the same endpoint shows the quota fine. So the transport is healthy; the built-in parser is what drops the data.

Why

zhipu_quota_from_body requires body.data:

let data = match body.get("data") {
    Some(d) => d,
    None => return make_error("Missing 'data' field in response".to_string()),
};

and parse_zhipu_token_tiers then requires data.limits.

GET /api/monitor/usage/quota/limit has also been observed returning the limit list as a bare top-level array, with no envelope at all. From the dump in the issue:

[
  {"type":"CREDIT_LIMIT","unit":3,"number":5,"usage":28000,"currentValue":2585,"remaining":25414,"percentage":9,"nextResetTime":1786592963348},
  {"type":"CREDIT_LIMIT","unit":6,"number":1,"usage":140000,"currentValue":58386,"remaining":81613,"percentage":41,"nextResetTime":1786692650981}
]

Against that body body.get("data") is None, so the parser returns Missing 'data' field in response before it ever looks at the entries.

Scope note

The issue titles the CREDIT_LIMIT type filter, but that half is already fixed on main — the filter accepts CREDIT_LIMIT alongside TOKENS_LIMIT, case-insensitively. The part that still reproduces is the envelope, which the reporter flagged separately at the end of the report. This PR covers only that, hence Refs rather than Fixes.

Change

Find the limit array where it actually is, rather than pinning one envelope shape — the bare array, or a limits array on whatever object we were handed. unit-based window classification and every other behaviour is untouched.

A body with no limits anywhere still returns an error, so a genuinely broken response is not silently converted into an empty-but-successful quota.

Tests

Three added:

• zhipu_quota_reads_a_top_level_limit_array — the reporter's real response verbatim, asserting both tiers and their percentages
• zhipu_quota_reads_limits_without_a_data_envelope — { "limits": [...] } with no data
• zhipu_quota_still_reports_a_body_with_no_limits_anywhere — an unrecognised body must still surface an error

Reverting the two source hunks and leaving the tests in place fails both new envelope tests with error: Some("Missing 'data' field in response") — the exact symptom from the report.

All 20 pre-existing zhipu* tests still pass unchanged.

cargo test --lib: 2480 passed, 2 failed. Both failures are codex_config::tests::resolve_catalog_rejects_symlink_escaping_config_dir and services::session_usage_grokbuild::tests::symlink_cycle_does_not_cause_stack_overflow, which panic with Os { code: 1314, "A required privilege is not held by the client." } — Windows refuses symlink creation without elevation, and they fail identically on the base commit. cargo fmt --check and cargo clippy --lib --all-features -- -D warnings are clean.