feat: per-site xBlock warning colour via XBLOCK_COLORS (EDLYPRODUCT-8495)

[muhammadali286]

What

Exposes the xBlock warning colours as CSS custom properties so a tenant can override the ORA "In Progress" badge colour from site configuration, with no theme rebuild.

Pairs with edly-io/edly-edx-themes#446 — both must be deployed for the badge to become configurable. Safe to merge in either order (see Backwards compatibility).

Why

Oryx reported the orange "In Progress" badge is off-brand and asked for their teal (EDLYPRODUCT-8495).

The colour was $xblock-color-warning: #F59810 — a compile-time SASS scalar in the theme, shared by every tenant on gestalt. There was no way to change it for one tenant without either recolouring it for all of them or forking the theme.

The panel Appearance UI only ever sends primary_color / secondary_color, and for Oryx both are already spoken for (primary #007A8A teal, secondary #76777A grey), so neither could carry the badge colour.

How

get_theme_colors() now merges an XBLOCK_COLORS dict into the emitted custom properties.

Why a dedicated XBLOCK_COLORS key rather than adding to COLORS: the panel does a wholesale replace of COLORS on every Appearance save — site_configurations[field] = request_data[field] in edly_panel_app/api/v1/views.py (only DJANGO_SETTINGS_OVERRIDE is merged). A key stored inside COLORS would be silently wiped the next time anyone touched Appearance. The panel never sends XBLOCK_COLORS, so it survives.

No template change needed — <theme>/lms/templates/main.html already loops every key of edly_colors_config into :root.

Backwards compatibility

DEFAULT_XBLOCK_COLOR_DICT holds the theme's existing values (#F59810 / #FFFAF1), and configuration_helpers.get_dict merges defaults under the site value. A site with no XBLOCK_COLORS emits exactly the same colours as today. The paired theme change also keeps the old SASS value as the CSS var() fallback, so this is safe to merge and deploy independently of the theme PR.

Configuring a tenant

site_values['XBLOCK_COLORS'] = {
    'xblock-color-warning':       '#007A8A',  # Oryx teal
    'xblock-color-warning-light': '#F0F8F9',  # tint for the step header
}

Set on the tenant's LMS, preview and CMS sites. Partial config is fine — unset keys fall back to the defaults.

Testing

See the test steps posted on EDLYPRODUCT-8495.

Key regression check: on a site with no XBLOCK_COLORS, .step__status__value must still compute to #F59810.