[FEATURE] Configurable / per-sender color for inbound peer (@ sender ›) and channel (← source:) message labels

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

I run a fleet of Claude Code sessions (several machines, several accounts) that talk to each other through the built-in cross-session messaging (unix inbox socket, SendMessage) and, since the research preview, through Channels. Both arrive in the terminal as a one-line header whose sender label has a hard-coded appearance that cannot be changed:

• Cross-session / peer messages render as @ <sender> › where the sender is always painted in the same fixed cyan (xz(undefined) → the default subagent-name color; the color picker only reacts to a subagent definition's color: field, and peer messages never carry one).
• Channel events render as ← <server>[ · <user>]: where the arrow is suggestion-colored and the label itself is dimColor — i.e. the least visible text on screen.

When ten or more sessions/senders are active, "who is talking to me right now" is the single most important bit of information on the line, and today it is either one fixed color for everyone or dimmed. There is no setting, env var, or theme key that affects either label (checked settings.json schema, /config, and the 2.1.234 renderer for UserCrossSessionMessage / UserChannelMessage).

Proposed Solution

Make the sender label of inbound peer / channel messages configurable, in one of these ways (any one would solve it):

1. A settings key, e.g. "peerMessageStyle": {"color": "yellow", "bold": true} and "channelMessageStyle": {...}, using the same palette already accepted for subagent color: (red blue green yellow purple orange pink cyan) plus bold / dim: false.
2. Or per-sender: let a peer/channel carry a display color the way subagents do — e.g. honor an optional color in the wire frame ({"type":"user", ..., "from": "…", "color": "yellow"}) and an optional color meta key on notifications/claude/channel, again restricted to the existing palette so it can't be abused for spoofing "human" styling.
3. At minimum: stop dimming the channel label (← khala: should be at least as visible as @ peer ›), and derive a stable color per sender name from the existing palette (hash of from), so different senders are distinguishable without any config.

Ideal UX: @ reviewer › in one color, @ builder › in another, ← khala · clawd@mini: bold, all still using the theme's palette so light/dark themes stay readable.

Alternative Solutions

• Prefixing the message body with unicode symbols/emoji (works, but the label itself stays fixed and dimmed, and the body is truncated to ~60 columns in the channel one-liner).
• Putting the sender into the channel user meta so it shows after · (works for text, not for visibility).
• Wrapping in a terminal that recolors by regex — fragile and defeats the purpose of the TUI doing it.

Priority

Medium - Would improve my workflow

Additional Context

Environment: Claude Code 2.1.233/2.1.234 native binary, Linux (Ubuntu, tmux) and macOS; multiple sessions coordinated with the cross-session inbox (crossSessionInbound: accept) and a development Channel plugin (--dangerously-load-development-channels plugin:…). Happy to test a build.