Bricks: add color swatches beside color variables in the variable picker dropdown

[devin-ai-integration]

Context

PR #182 disabled the Bricks color-palette injection on Bricks 2.2+, because the new Color Manager materializes every palette color into :root as a static value (light == dark in our case), which overrides the framework's adaptive light-dark() --sf-color-* tokens and breaks dark/light switching. SLASHED tokens now reach the builder only through the Variable Manager (empty-value entries that Bricks never writes to :root).

The trade-off: we lost the color swatches that the palette dropdown used to show. The variable picker still lists --sf-color-* and previews on the canvas when you hover a variable, but there are no colored squares next to the entries in the dropdown list.

Goal

Restore at-a-glance color swatches without re-introducing any :root overrides — i.e. keep dark/light fully framework-driven.

Proposed approach (preferred): custom builder-side decoration

Keep the Bricks variables empty-valued (no :root impact) and enqueue a small script into the Bricks builder that decorates each color entry in the variable-picker dropdown with a colored square.

• We already compute the --sf-color-* → hex map server-side: Slashed_Bricks_Inventory::get_color_hex_map() (resolver in integrations/bricks/includes/class-color-resolver.php). Localize that map to JS.
• Use a MutationObserver on the variable dropdown to paint a <span> swatch next to matching entries as they render (the list can be virtualized, so observe rather than one-shot).
• Swatch fill must use the resolved hex, not var(--sf-color-*): the builder admin panel intentionally does not load the SLASHED CSS (see class-enqueue.php), so var() can't resolve there. Consider a split light/dark square so both modes preview at a glance (resolver would need to also emit the dark hex).
• Builder-enqueue infra already exists (the reBEMer editor app is enqueued into the builder main panel via class-rebemer-enqueue.php).

Caveat

This hooks Bricks' internal builder DOM, which is unsupported and can shift between Bricks releases (2.2 reworked the Style Manager UI). Match on the most stable hooks available and fail silently so a Bricks update can never break the picker — just drop the swatches until we update selectors.

Alternative considered: native swatch via chaining variables

Give the injected variables a non-colliding name + value var(--sf-color-*) so Bricks emits :root { --slashed-color-primary: var(--sf-color-primary) } (adaptive, no clobber). Rejected as the primary path because: the panel still can't render a swatch (no SLASHED CSS there), it changes what's inserted (var(--slashed-color-primary) indirection), and it re-expands the :root surface.

Acceptance criteria

• Color variables show a swatch square in the variable-picker dropdown in the Bricks 2.2+ builder.
• No --sf-color-* (or alias) is written to :root by this feature; dark/light still driven by the framework's light-dark().
• Swatch reflects the resolved color; ideally previews both light and dark.
• Degrades gracefully (no console errors / no broken picker) if Bricks changes its builder DOM.

References

• PR fix(bricks): skip color-palette injection on Bricks 2.2+ Color Manager #182 (the gating fix this follows up on)
• integrations/bricks/includes/class-colors.php — should_inject_palettes() / slashed_bricks/inject_color_palette filter
• integrations/bricks/includes/class-variables.php — empty-value variable injection
• integrations/bricks/includes/class-color-resolver.php / class-inventory.php — hex map source
• integrations/bricks/includes/class-rebemer-enqueue.php — existing builder enqueue pattern