Ultracode arms with no ultracode setting in any scope; header shows plain "with xhigh effort" while it is active

Supporting doc citations for "no sanctioned route to this state" (checked against current docs + full CHANGELOG):

• Documented Fable 5 default effort is high, not ultracode: model-config "Adjust effort level", resolution step 4 — "The model's default effort: high on every model that supports effort, except that Opus 4.7 defaults to xhigh..." The only documented route to a different default is an organization-set default effort for the org default model; this is a personal Max account, so it does not apply.
• The Fable 5 "hold" (step 2) holds the model default across sessions — which per the docs is high, so the hold cannot explain an ultracode start either.
• ultracode settings key: "Default: unset, so ultracode is off."
• CHANGELOG has no entry in any version about ultracode becoming a default, being bundled with a model, or the slider's default position changing. Nearest relevant entry suggests recent churn in exactly this area: 2.1.243 — "Fixed the /model picker silently ignoring an Ultracode selection; picking Ultracode now applies it to the current session."
• The header reading "with xhigh effort" while ultracode is active is consistent with the statusline doc's "Ultracode is not a distinct level and reports as xhigh" — i.e. the header appears to be rendering the reported level, which hides the workflows flag.

Confirming this on Windows 10 Pro (10.0.19045), Claude Code CLI - same symptom:
the session is armed with ultracode while the header reports plain xhigh.

Worth stating the root cause explicitly, because it makes this bug and an existing
feature request the same work item: the status line's stdin JSON carries no field
for ultracode at all - effort.level collapses ultracode and xhigh onto the same
value. So the built-in header and every custom status line are structurally unable
to tell the two apart. That is exactly what #69068 asks for (effort.ultracode: true
in the payload).

This therefore cannot be fixed cosmetically. Fixing the header requires making the
ultracode state observable, which is #69068 - closing that one closes this for free,
whereas patching only the TUI would leave every custom status line still wrong.

Related: #90744 (ultracode unobservable, and not inherited by spawned sessions).

Second data point, and it isolates the "no setting in any scope" half of this report.

Environment: Windows 10 Pro (10.0.19045), Claude Code CLI 2.1.252, Opus 5 (1M context).
Different OS build, different CLI build and different model from the original report
(Windows 11 / 2.1.251 / Fable 5), same behaviour - so this is not build- or model-specific.

Reopening /effort (then Esc, to avoid changing anything) puts the slider marker on
ultracode, and the session confirms it with Set effort level to ultracode
(this session only).

Meanwhile every persisted scope on disk says xhigh:

| scope | value |
|---|---|
| ~/.claude/settings.json -> effortLevel | "xhigh" |
| ~/.claude/settings.json -> modelSettings["claude-opus-4-8"].effortLevel | "xhigh" |
| ~/.claude/settings.json -> modelSettings["claude-opus-5"].effortLevel | "xhigh" |
| ~/.claude/settings.local.json | file does not exist |
| project .claude/settings.json | file does not exist |
| project .claude/settings.local.json | no effort key |

Grepping every settings file for the string ultracode returns nothing. The only place
that word exists anywhere on disk is a session title I typed by hand as a workaround
("customTitle": "@Active [✦ ultracode]", nameSource: "user") - which is rather the
point: the only way to see the state is to write it down yourself.

So the arming is real, session-only, and recorded nowhere. That is why no consumer can
derive it: not the header, and not a custom status line either, since the statusLine
stdin JSON has no field for it and effort.level reads xhigh. This is the same root
cause as #69068 - one fix closes both.