Hardcoded indigo colors bypass the primary-color theme tokens

Summary

app.css defines a theme-aware primary palette (--color-primary-50 through --color-primary-950, currently mapped to indigo), but a number of templates and components hardcode bg-indigo-* / ring-indigo-* / text-indigo-* classes instead of bg-primary-* / ring-primary-* / text-primary-*. If the primary color is ever re-themed, those surfaces stay indigo while the rest of the app shifts.

Where

Currently 23 files, ~58 occurrences. Run grep -rln "bg-indigo\|ring-indigo\|text-indigo" lib/lightning_web/ for the live list. Hotspots:

• lib/lightning_web/components/pills.ex
• lib/lightning_web/live/sandbox_live/components.ex
• lib/lightning_web/live/workflow_live/edit.ex
• lib/lightning_web/live/project_live/settings.html.heex
• lib/lightning_web/live/workflow_live/components.ex
• lib/lightning_web/live/workflow_live/dashboard_components.ex

Fix

Mechanical rename: indigo-NNN -> primary-NNN everywhere a class is part of the primary brand surface. Skip places where indigo is a literal semantic choice (status pills, color picker swatches). One PR.

Start by reading app.css to understand the primary color tokens, then run grep -rln "bg-indigo|ring-indigo|text-indigo" lib/lightning_web/ to inspect the 23 affected files and the listed hotspots. Replace indigo classes only on primary brand surfaces, preserving semantic status pills and color-picker swatches, then confirm the resulting class usage across the live list.