Feature Request: Expose active effort level in statusline input JSON

Summary

statusLine.command receives a JSON blob on stdin (.statusline-input.json) with model/context/rate_limits/etc., but the current effort level is not included. This prevents statusline scripts from displaying the actual runtime effort being used for inference.

Current state (v2.1.112)

The JSON fields provided to the statusline command include:

• model.id, model.display_name
• context_window.used_percentage
• rate_limits.five_hour, rate_limits.seven_day
• workspace, cwd, version, cost, output_style, etc.

No effort / reasoning_effort / effortLevel field.

Problem

A user's statusline can read effortLevel and env.CLAUDE_CODE_EFFORT_LEVEL from settings.json directly, but this does not reflect the actual runtime effort:

• /effort <value> changes the effort for the session, but this change is never exposed outside Claude Code (no file, no stdin field, no transcript entry)
• effortLevel: "max" in settings.json is "session-only, falls back to xHigh default" per docs, so what the user writes is not necessarily what Claude Code applies (see also #33937, #48051)
• Result: the statusline can show max while the session is actually running at xHigh, or vice versa

This makes it impossible to build an honest "what effort am I actually paying for right now?" indicator.

Proposed change

Add reasoning_effort (or effort) to the statusline stdin JSON:

{
  ...
  "reasoning_effort": {
    "active": "xhigh",
    "source": "env"  // "env" | "settings" | "/effort" | "default"
  }
}

• active: the effort level the next request will be sent with
• source: where this value originated from (helps the user debug if their settings aren't taking effect)

Why it matters

1. Honest display: users currently have to choose between reading settings.json (inaccurate when /effort is used) or (cfg.env) (inaccurate when settings.json "max" is silently downgraded). Neither is the truth.
2. Cost transparency: xhigh and max have different token consumption profiles; users on Max plans want a visible indicator of the current level
3. Debuggability: the source field makes settings conflicts self-explanatory (e.g., "your /effort max was ignored because env var forces xhigh")

Workaround (for reference)

Currently users must:

• Read settings.json and hope no /effort override was applied this session
• Run /effort manually to check, which is interactive and cannot be scripted from the statusline

Neither is suitable for a statusline.

Related issues

• #33937 — effort level 'max' should be persistable
• #48051 — effortLevel "max" runs as medium
• #30726 — effort silently downgraded

Exposing the effective value in the statusline would also help surface these bugs to affected users automatically.