[UI] Show provider subscription usage in the thread details card on Web / Desktop App

[faetschi]

Problem

Subscription limits — the 5-hour / weekly / monthly quota windows a provider
reports for the signed-in account — are only visible in the full Usage → Limits
page (mod+u) or in the ephemeral /usage-limits composer notice, which appears
on demand and dismisses when the thread, model, or turn changes.

Nothing beside the chat answers "how much of this window is left?" while you decide
whether to start another turn. Other agent workspaces like OpenChamber keep a compact usage readout
in the thread-context panel for this reason, and there is already appetite for it
here: #17868 asks for a sidebar warning when a window drops below 10%.

Example from OpenChamber Web UI's Thread Details Card:

Proposal

Add a Usage section to the thread details card (the panel beside the chat that
already shows Workspace, Version Control, Automations, and Lineage). It builds on
the existing provider usage-limits data and the same pooling the Limits page uses,
so it cannot drift from the page:

• A collapsible header whose headline is the session provider's window
  closest to running out, shown as Session X% used. Another provider's tighter
  window never reads as this session's; if the session's provider reports nothing,
  no number is shown, and the expanded rows still list every provider.
• Expanded, per-provider groups that each expand/collapse, with
  provider-prefixed window rows (Codex · Session), each showing its share used, a
  thin bar, and the next reset (↻ 1h 50m). Per-provider collapse choices persist.
• Quota used throughout, with the number and bar amber past 60% used and red
  past 90%.
• A Refresh action, plus automatic refresh.
• Settings → General gains two controls: Usage refresh interval
  (30s / 1m / 5m / manual; default 1m) and Usage headline window (closest to
  running out by default, or a fixed session / weekly / monthly).
• The section hides itself when no connected provider reports windows, so an
  environment without subscriptions gains no empty section.

No server or contract behaviour changes: the report is assembled client-side from
ServerProvider.usageLimits and usageLimitSources, which already stream to
clients.

From experimenting with T3 nightly fork:

Before:

After:

Collapsed:

Expanded:

Usage limit over 60% (amber) / over 90% (red)

Usage collapsed, Red headline (over 90%), showing tightest window at 94% used:

Reference to Usage in Settings - General (might not be the best place for this)

Scope / non-goals

• Not the Usage page: its Limits and cost/token views are unchanged.
• Not the /usage-limits command or the composer notice.
• Not the <10% warning from Warning if you are below 10% usage for limit #17868 — a separate behaviour that could build on this.
• Mobile is deliberately untouched: mobile has its own Usage screen
  (apps/mobile/src/features/usage/*), and there is no thread-details card there.

Open question

Is the thread details card the right home for this? Happy to prepare a focused PR once the direction is approved.

[HarryCarter1998]

I'd also like an option to keep subscription usage visible at all times while working in a conversation.

At the moment, checking my allowance means opening Usage → Limits or repeatedly invoking /usage-limits. The temporary composer display disappears when I send another message, so it does not solve the need to keep an eye on usage during ongoing work.

The right-hand thread details panel would be a useful home for a compact, optional usage section alongside the existing workspace and Git controls. I'm flexible about the exact location; the main requirement is that it can stay visible while I read, send messages, and watch the agent work, without switching views.

Ideally it would show the current provider/account's remaining subscription allowance, the relevant session and weekly windows, and reset times, with automatic refresh and a way to hide or collapse it. My main interest is subscription allowance rather than estimated API dollar cost.

Please consider making this a configurable, persistent display on desktop/web.