chat-blue: misleading name on an orphaned theme, and the entity-color link is inverted

[aidanhb]

Spun out of #6021, where chat-blue came up while adding a markdown checkbox style hook. Filing the findings before the reasoning goes cold. Not urgent — nothing is visibly broken, because the mechanism is currently unreachable.

1. channelThemeSender is orphaned

channelThemeSender (LexicalMarkdown/theme.ts) has exactly one consumer: the debug page MarkdownParseTestPage.tsx.

Channel messages render with channelTheme, unconditionally, with no sender/receiver branching:

// features/channel/Message/Content.tsx:37
<StaticMarkdown markdown={content()} theme={channelTheme} … />

So everything channelThemeSender defines is currently dead outside the debug page:

• chat-blue on text.code, code, user-mention, document-mention, listitemChecked
• the text-current/N de-emphasis overrides (listitemChecked, quote)
• the bg-[navy]/20 / border-[navy]/23 code tints
• the === 'chat-blue' monochrome branch in DocumentMention.tsx
• .md-list.md-check > li.checked.chat-blue::before in styles.css

Worth deciding whether this is a regression (a sender theme that was wired up and got orphaned, plausibly in the frontend restructure) or dead weight to delete. If it's a regression, sender-authored messages are silently missing their intended treatment.

2. The name describes a color it never applies

There is no .chat-blue { … } rule anywhere. The class paints nothing. Its real uses are:

• a sentinel, string-compared to detect the theme:

  // DocumentMention.tsx:351
  props.theme?.['document-mention'] === 'chat-blue' ? 'monochrome' : undefined

• a CSS qualifier in two styles.css selectors

3. The entity-color link is inverted, and the color is wrong anyway

The per-block entity colors in index.css ("Entity colors are aliases of the authored named palette") are consumed by EntityIcon as text-chat / bg-chat/20. chat-blue's actual job is to make embedded entity mentions render monochrome — i.e. to suppress those identity colors via monochromeIcons.ts, which flattens --color-chat, --color-canvas, --color-task and friends to var(--c0).

So the name asserts an entity color while the behavior negates all of them. And the color is wrong regardless:

Token	Value
--color-chat	cyan
--color-write, --color-folder	blue

4. Naming is genuinely open

The obvious rename — something like on-bubble — doesn't hold up: chats aren't reliably rendered on a bubble, only when selected or highlighted from being linked to. So the invariant isn't "there is a bubble."

The real invariant is closer to "derive colors from the container rather than asserting the ink and entity palettes" — which holds whether or not a bubble is painted. Naming it after the theme that sets it (channel-sender) may be more honest than naming it after a visual condition that isn't dependable.

Best resolved together with (1): if the sender theme should be live, the name should describe the live behavior; if it's dead, this deletes rather than renames.

Not doing this in #6021

That PR adds checklist: 'md-list md-check chat-blue' to channelThemeSender plus a .md-list.md-check.chat-blue rule. Renaming touches five theme values, a === sentinel whose behavior a rename can silently break, and three selectors — its own change, with its own review.