Semantic classes for UI components

The current Emotion-based override system is powerful, but it has a few downsides:

• no syntax highlighting or validation unless you use Emotion's object-based CSS and you install its types, or use specific IDEs (e.g. Intellij Idea Ultimate) with Emotion's css`...` string template.
• no obvious mapping between overrides and DOM elements, which complicates prototyping and debugging from the browser.
• no easy way to style children from a parent override: one must either use CSS variables to pass data between the two overrides, or rely on the precise DOM structure (which we may change at any time).

One way to solve these issues would be to add classes to every element that uses overrides.

One foreseeable pitfall to this approach would be that class-based CSS overrides may conflict with emotion-generated CSS. In those cases, some specificity hacks may be required.

The issue names no files, tests, or entry points. Start by locating the Emotion-based override implementation and the components that use it, then determine how semantic classes and class-based child styling should work alongside generated CSS. Done means the approach is defined and documented or implemented with conflicts addressed.