[FEATURE] Expose live ultracode session state in the statusline stdin JSON

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

Ultracode's session-active state cannot be read by a statusline script. The stdin JSON passed to the statusLine command carries no ultracode field, and effort.level does not reflect it: on 2.1.199, with "ultracode": true in settings.json and ultracode active for the session, the statusline JSON reports "effort": {"level": "low"} (the persisted effortLevel).

Reading settings.json from the statusline script is not a substitute, because the persisted ultracode key is the default for new sessions, not the live state. The two diverge whenever:

• the session model is switched to one that doesn't support ultracode (key stays true, session state goes inactive), or
• /effort <level> is used mid-session, which clears session ultracode without touching the key.

The session state lives only in the CLI process's memory — it is not in the statusline JSON, the transcript JSONL, or any file on disk (the shared app-state persistence only covers frameUrls). So there is nothing truthful for a statusline to display.

Proposed Solution

Add an explicit field to the statusline stdin JSON reflecting the live session state, e.g.:

"ultracode": { "active": true }

set from the same session app state the CLI uses internally (getAppState().ultracode), so it tracks model switches and /effort changes within the session.

Alternative Solutions

• Reading the ultracode key from settings.json in the statusline script — rejected above (shows the default, not the live state).
• Inferring from effort.level — currently inconsistent across entry points; see #77812, which documents /effort ultracode reporting "ultracode" while the model-picker path reports "xhigh", and this report adds a third case: settings-key-enabled ultracode reports the plain persisted level ("low"). A dedicated field would also resolve that ambiguity without overloading effort.level.

Priority

Low - Nice to have

Feature Category

Interactive mode (TUI)

Use Case Example

1. settings.json has "ultracode": true; statusline shows an "ultra" tag based on any currently available signal.
2. Mid-session, run /model sonnet or /effort low — ultracode deactivates for the session.
3. The statusline keeps showing "ultra" (settings key unchanged) or never showed it correctly (effort.level says low), so the user can't tell whether their next prompt will run with workflow orchestration.
4. With ultracode.active in the statusline JSON, the tag would track the real state.

Additional Context

Observed on 2.1.199 (linux-x64). The docs statement "Ultracode is not a distinct level and reports as xhigh" (statusline.md) did not match observed behavior in this configuration — effort.level stayed "low" while ultracode was active via the settings key.