[BUG] First /rename silently replaces the theme's prompt-bar color with default teal

Description

When a session has no displayed name, its input-box bar uses the active
theme's promptBorder color. The first /rename on that session (the
command that gives it a name) silently replaces that with the
session-name bar's default color, a hardcoded teal, discarding the theme
color.

/rename is a naming command. Nothing indicates it also recolors the
prompt bar. The result looks like the theme broke. There is no way to get
the theme color back on a named session, because /color only offers 8
fixed named presets, none of which is the theme's value.

Steps to reproduce

1. Start a session with a custom theme active and no displayed name. The

input-box bar shows the theme's promptBorder color.

1. Run /rename SomeName.
2. The bar immediately changes to the default teal.

Expected

/rename names the session without altering the prompt bar color. If a
named session must use the session-name bar, that bar should default to
the theme's promptBorder, not a hardcoded teal.

Actual

The first /rename silently swaps the theme promptBorder color for the
default teal.

Why this matters

Tracing this to root cause took several hours. The visible symptom is
only "the prompt bar is the wrong color," with nothing connecting it to
/rename or to the session-name display. The theme picker, the theme
files, and the promptBorder token all look correct and untouched
throughout. A naming command silently mutating an unrelated visual
element, with no notice, is the core problem.

Environment

• Claude Code 2.1.143 (where observed)
• macOS

Related

#61029 is a related feature request (make the session-name bar themeable
or hex-configurable). This is filed as a separate bug because the two are
distinct: #61029 asks for new capability, while this issue is about
/rename silently discarding an existing, correct color with no
indication it did so.