[FEATURE] Token burn-rate 'speedometer' per session and overall, so you can see which session is redlining before the budget is gone

### Preflight Checklist

- [x] I have searched existing issues and this is not a duplicate
- [x] This is a feature request, not a bug report

### Problem Statement

Claude Code shows how much budget is **left** (the "gas tank" via `/usage` and the status line), but it gives no visibility into what is **burning** that budget right now, or how fast.

When running several sessions in parallel (desktop app, FleetView, multiple terminals), the only way to guess which session is expensive is to look for the one with the most subagents running. That is a poor proxy: a single session with a huge context and a long tool loop can out-burn three sessions with subagents.

The failure mode is walking away for an hour and coming back to find the 5-hour or weekly budget fried, because one session nobody was watching was redlining the whole time. There is no signal that would have flagged it, and after the fact there is no way to tell which session did it.

Related but distinct: #85422 asks for enforced spend caps and #92708 asks for cumulative usage in FleetView. This request is about **rate**, not caps or totals: a live burn-rate indicator so the user can spot the hot session before the budget is gone.

### Proposed Solution

Add a **burn-rate "speedometer"** (tokens per minute, or budget-percent per hour) at two levels:

1. **Overall**: one gauge for the account showing current aggregate burn across all active sessions, next to the existing remaining-budget indicator.
2. **Per session**: a small gauge or sparkline in the session list / FleetView / status line for each session, so the hottest session is visually obvious at a glance.

Details:

- Smooth the rate over a trailing window (roughly the last 10 minutes) so the gauge does not flicker with every turn. A sparkline of the same window works too, and shows trend as well as level.
- Show the number in a useful unit: tokens/min is fine, but "% of 5h budget per hour" or "time to empty at current rate" is what actually answers "should I be worried?".
- Color thresholds (green / amber / red) relative to a sustainable rate, i.e. the rate at which the budget would run out exactly at the reset boundary.
- Include subagent and background-agent spend in the parent session's rate, since that is where the surprise usually comes from.
- Optional: a desktop notification when any session stays in the red band for more than N minutes, or when projected time-to-empty drops below the time to the next reset.

### Alternative Solutions

- Expose per-session token counts and timestamps in a machine-readable way (statusline JSON, a hook event, or a local endpoint) so third-party tools can compute the rate. Less discoverable, but unblocks the community.
- A `/usage --by-session` command that lists sessions sorted by tokens consumed in the last 10 minutes. Not live, but would still answer "which one is doing this?".

### Priority

High - significantly impacts workflow

### Feature Category

UI/UX improvements

### Use Case Example

I have four sessions open: two doing focused edits, one running a long QA loop with subagents, and one I forgot about that is looping on browser automation with a near-full context. I go to lunch. Today: I come back to 4% weekly budget left and no idea which session did it. With this feature: the forgotten session's gauge has been pinned in the red for 40 minutes, the overall gauge shows time-to-empty under an hour, and I would have gotten a notification and killed it before eating.

### Additional Context

The mental model is a car dashboard. Remaining budget is the fuel gauge. What is missing is the tachometer, and ideally a "miles to empty" estimate, so the driver can see they are redlining before the tank is dry. Per-session attribution is the part that makes it actionable: knowing the account is burning fast without knowing *where* still leaves the user guessing.