fix(zai): accept CREDIT_LIMIT quota entries

[taimurrabuske]

What happens

The Z.ai provider renders the grey "No usage data" badge even though the API
key is valid and the account has an active, in-use GLM Coding plan. The request
itself succeeds — the plan name is picked up correctly from the subscription
endpoint, so only the quota payload goes unrecognised.

Root cause

Current Z.ai coding plans return quota entries typed CREDIT_LIMIT rather than
TOKENS_LIMIT:

// illustrative values; structure is verbatim from a live account
{
  "code": 200,
  "data": {
    "limits": [
      { "type": "CREDIT_LIMIT", "unit": 3, "number": 5, "usage": 2000,  "currentValue": 40, "remaining": 1960, "percentage": 2, "nextResetTime": 1788029492559 },
      { "type": "CREDIT_LIMIT", "unit": 6, "number": 1, "usage": 10000, "currentValue": 40, "remaining": 9960, "percentage": 1, "nextResetTime": 1788616038998 }
    ],
    "level": "<plan level>"
  },
  "success": true
}

plugins/zai/plugin.js matches only TOKENS_LIMIT:

• plugin.js:120 — findLimit(limits, "TOKENS_LIMIT", 3) (session)
• plugin.js:142 — findLimit(limits, "TOKENS_LIMIT", 6) (weekly)

With only CREDIT_LIMIT entries present, tokenLimit is null, the early
return at plugin.js:122 fires, and the badge is rendered despite real usage
being reported.

The (unit, number) window encoding is unchanged — unit: 3 is the 5-hour
session window and unit: 6 the weekly one — and percentage is still supplied
directly, so no other mapping needs to change.

Fix

Match either type, so both plan generations keep working:

const tokenLimit = findLimit(limits, "TOKENS_LIMIT", 3) || findLimit(limits, "CREDIT_LIMIT", 3)
const weeklyTokenLimit = findLimit(limits, "TOKENS_LIMIT", 6) || findLimit(limits, "CREDIT_LIMIT", 6)

This is the same resolution accepted upstream in OpenUsage
(robinebers#1104, closed), which recommends treating CREDIT_LIMIT
exactly like TOKENS_LIMIT for the session and weekly meters and keeping the
window classification and percentage mapping as-is.

TIME_LIMIT handling is untouched. Accounts without a web-search allowance
return no TIME_LIMIT entry, and omitting that line for them is already correct.

Tests

Adds a CREDIT_LIMIT fixture to plugins/zai/plugin.test.js covering the
session and weekly meters, alongside the existing TOKENS_LIMIT cases.

npx vitest run plugins/zai/plugin.test.js — 25 passed. With the plugin.js
change reverted the new test fails as expected
(AssertionError: expected 'badge' to be 'progress'), so it genuinely covers
the regression rather than passing either way.

Verified

Applied against Tuxmeter 0.0.2 on Ubuntu (GNOME 50, Wayland) with a live
GLM Coding account. Before the change the provider cached a single
badge line reading "No usage data"; after it, the session and weekly
progress lines populate with the correct percentages and reset times.