[FEATURE] Expose subscription billing-cycle / renewal date in statusline JSON (or via CLI)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The statusline stdin JSON currently exposes rate_limits.five_hour and rate_limits.seven_day, each with a used_percentage and resets_at — great for rolling usage windows. There's no equivalent field for the monthly subscription billing cycle (i.e. the date Pro/Max renews). Statusline tools that want to show "days until renewal" or a billing-cycle progress bar currently have no way to compute this automatically.

Proposed Solution

Add a field to the stdin JSON already sent to statusLine commands, alongside the existing rate_limits object, e.g.:

{
  "rate_limits": {
    "five_hour": { "used_percentage": 23, "resets_at": 1751234567 },
    "seven_day": { "used_percentage": 41, "resets_at": 1751654321 },
    "billing_cycle": {
      "started_at": 1752444000,
      "renews_at": 1755036000
    }
  }
}

• started_at / renews_at as epoch seconds, consistent with how resets_at is already represented for the other two windows.
• Only populated for subscription (Pro/Max/Team) sessions, same conditional population pattern already used for rate_limits today (i.e. absent entirely for API-key/OpenRouter backends, exactly like five_hour/seven_day are).

If a JSON field isn't feasible short-term, even a documented CLI command (e.g. claude billing status --json) that a statusline script could shell out to would unblock this — though the stdin field is strongly preferred since it avoids an extra process spawn on every statusline render.

Alternative Solutions

• Manual local tracking (what we do today): user enters renewal date once, tool assumes a fixed 30-day cycle and self-rolls forward. Works until the actual billing date shifts (upgrade/downgrade, proration, plan change), at which point it silently drifts and shows an inaccurate progress bar with no way to detect the drift.
• Scraping the account/billing page: fragile, unsupported, and not something a local CLI tool should be doing.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

This came up while building a statusline that mirrors the existing 5h/7d rate-limit bars with a third "time left in billing cycle" bar. The 5h/7d precedent already establishes that Claude Code is willing to expose rolling-window usage/reset data to statusline scripts — this would just extend that same pattern to the monthly billing cycle.

Happy to provide more detail on the intended statusline layout if useful.