Chat-room admin templates hardcode #dc2626 for danger button + JS error text instead of --color-danger (renders wrong red in dark theme)

Area: Admin deep-dive (commerce/config) (audit p15b) · Surface: /admin/chat-rooms/{id}/edit and /admin/chat-rooms/new · Dimension: Law 3 (semantic tokens, contrast in every theme) · Severity: minor

In dark theme these elements render the darker light-theme red (#dc2626) rather than the lighter #ff7070 the design system switches to for dark backgrounds, reducing contrast. Hardcoding defeats the token's whole purpose (per memory: use semantic tokens, never raw colors).

Evidence

A semantic token exists: public/css/style.css defines `--color-danger: #dc2626` (light) and `--color-danger: #ff7070` (dark). But templates hardcode the light-theme value: chat-rooms/edit.php:191 `.mcn-btn--danger { color: #dc2626; }` (the Archive button), and inline JS error hints at chat-rooms/new.php:414 & :423 and chat-rooms/edit.php:418 & :427 all do `hint.style.color = '#dc2626';`. Same in courses/form.php:433 `<span style="color:#dc2626;">*</span>`. The same templates use semantic tokens for everything else (e.g. .mcn-btn--ghost uses `var(--color-text-muted)`), so the dark-mode-aware token is intentional and being bypassed.

Suggested fix. Replace the hardcoded #dc2626 with var(--color-danger) in the CSS rule, and set `hint.style.color = ''` + a CSS class (e.g. .mcn-field-error { color: var(--color-danger); }) instead of an inline hex in the JS. Do the same for the courses/form.php required asterisk.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.