Expose thinking token counts in statusline JSON input

Summary

The JSON object passed to custom statusline scripts (context_window) includes total_input_tokens and total_output_tokens, but does not include thinking/reasoning tokens. This makes it impossible to calculate accurate session cost from a statusline script — on Opus, thinking tokens are often the dominant cost component.

Current behavior

The context_window object provides:

{
  "total_input_tokens": 150000,
  "total_output_tokens": 5000,
  "used_percentage": 23
}

A statusline script can compute cost from these, but the result significantly underestimates actual spend because thinking tokens are invisible.

Requested change

Add total_thinking_tokens to the context_window object passed to statusline scripts:

{
  "total_input_tokens": 150000,
  "total_output_tokens": 5000,
  "total_thinking_tokens": 42000,
  "used_percentage": 23
}

The data already exists — the API response includes thinking token counts. Claude Code just needs to accumulate them and surface them in the statusline input, the same way it already does for input and output tokens.

Why this matters

• The statusline is the only in-session cost indicator available to users (there is no /usage or /cost command)
• On Opus, thinking tokens can be 3-10x the visible output tokens and are often the single largest cost component
• Users building custom statuslines for cost tracking (which Claude Code encourages via the statusline API) get a misleadingly low number
• The model name is already available in the statusline JSON, so with thinking tokens exposed, scripts can apply correct per-model pricing for all three token types

Related issues

• #49320 — requests thinking_tokens in the raw API usage response (API-level; this issue is about the statusline data pipeline)
• #31585 — requests thinking tokens in OpenTelemetry metrics (telemetry-level)
• #49745 — broader cost estimation blind spots (thinking tokens are one contributing factor)

This is a narrowly scoped change: accumulate thinking tokens from API responses and include them in the existing statusline JSON object.