[Feature] Theming system — overridable color palette instead of hardcoded constants

[fissible]

Source: external review report, 2026-08-24 (notable exclusion #2)

Gap

Colors are hardcoded constants (SHELLFRAME_GRAY, etc.) except toast's ad-hoc theme override. Any embedder wanting brand colors must sed the source.

What it needs

• A palette of semantic roles, not raw colors: SHELLFRAME_THEME_BORDER, _TITLE, _ACCENT, _MUTED, _ERROR, _SUCCESS, _SELECTED_BG, _SELECTED_FG
• Defaults set with : "${SHELLFRAME_THEME_BORDER:=$'\033[90m'}" so consumers override by exporting before source shellframe.sh
• Widgets read roles, never raw constants; keep the old SHELLFRAME_GRAY names as aliases for one release
• Fold toast's override into the same mechanism
• Optional: shellframe_theme_load path/to/theme.sh and one or two shipped themes (default, mono/no-color)
• NO_COLOR env var honored (https://no-color.org)

Tests

• Unit: export a role, source, render confirm → escape present in output
• Unit: NO_COLOR=1 → no SGR sequences emitted

Effort: M
Deps: #42 (H2) (so %b is only ever applied to theme constants — theming makes that boundary explicit)

[fissible]

Shipped: shellframe_theme_load (name or path), shipped default+mono themes, theme_list, fail-closed error handling, SHELLFRAME_YELLOW defined. #42 groundwork made this small — colors were already %s-safe named constants, so theming = reassignment at load time. v2-runtime region-level theme hooks deferred unless consumers ask.