v0.3.3 - Fix style variation bridge to read from theme palette origin

WordPress puts active variation colors in the 'theme' palette origin,
not 'custom'. Detection now compares theme origin against base defaults.

Co-Authored-By: Claude <noreply@anthropic.com>

CLAUDE.md

@@ -34,7 +34,7 @@ This project is proudly **"vibe-coded"** using Claude.AI - the entire codebase w
 
 **Note for AI Assistants:** Clean this section after the specific features are done or new releases are made. Effective changes are tracked in `CHANGELOG.md`. Do not add completed versions here - document them in the Session History section at the end of this file.
 
-Current version is **v0.3.2** - Dark Mode Bugfix. Next milestone is **v1.0.0 - Release**. See `PLAN.md` for details.
+Current version is **v0.3.3** - Style Variation Bridge Fix. Next milestone is **v1.0.0 - Release**. See `PLAN.md` for details.
 
 ## Technical Stack
 
@@ -193,24 +193,25 @@ Build steps (in order):
 
 ## Session History
 
-### Session 7 — v0.3.2 Dark Mode Bugfix (2026-02-08)
+### Session 7 — v0.3.2/v0.3.3 Dark Mode & Style Variation Bridge (2026-02-08)
 
-**Completed:** Fixed dark mode rendering conflicts between WordPress global styles and Bootstrap, fixed form element styling in dark mode, bridged style variation colors to Bootstrap CSS custom properties.
+**Completed:** Fixed dark mode rendering conflicts between WordPress global styles and Bootstrap, fixed form element styling in dark mode, bridged style variation colors to Bootstrap CSS custom properties, fixed variation detection to read from correct palette origin.
 
 **What was built:**
 
 - Style variation bridge function (`wp_bootstrap_variation_colors`) that maps WordPress palette colors to Bootstrap CSS custom properties via `wp_enqueue_scripts`
 - Helper functions for color manipulation: `wp_bootstrap_hex_to_rgb()`, `wp_bootstrap_build_surface_css()`, `wp_bootstrap_mix_hex()`, `wp_bootstrap_hex_to_rgb_array()`, `wp_bootstrap_relative_luminance()`
-- Detection logic to skip bridge when no variation is active (checks for theme slugs in `custom` palette origin)
+- Variation detection comparing `theme` origin palette against hardcoded base defaults (base, contrast, primary)
 - Dark mode body override in `_custom.scss` using `!important` to defeat WordPress global styles specificity
 - Broad dark mode rules for all native form elements (`select`, `input`, `textarea`) to catch plugin-generated controls
 - Fixed `footer-columns.html.twig` to use semantic `bg-body-tertiary` instead of hardcoded `bg-dark text-light`
 
 **Key learnings:**
 
-- `wp_get_global_settings(['color', 'palette'])` returns keyed sub-arrays (`default`, `theme`, `custom`) but may omit origins; query each origin separately with `wp_get_global_settings(['color', 'palette', 'default'])` etc.
+- WordPress puts style variation colors in the `theme` palette origin, NOT `custom` -- `wp_get_global_settings(['color', 'palette', 'theme'])` returns the base theme.json merged with the active variation
+- The `custom` palette origin contains user manual edits from the Site Editor, but its data structure may lack expected `slug`/`color` keys
+- To detect an active variation, compare `theme` origin colors against known base theme.json defaults rather than checking for slugs in `custom`
 - WordPress `theme.json` `styles.color` generates `body { background-color: var(--wp--preset--color--base) }` directly on `body`, which overrides inherited CSS variables from `html[data-bs-theme="dark"]` -- removing `styles.color` from theme.json is the cleanest fix
-- The `wp_global_styles` custom post type stores user-saved variation settings; when empty, no variation has been selected by the user
 - CSS variables defined directly on `body` beat inherited values from `html` due to specificity, requiring `!important` on `html[data-bs-theme="dark"] body` to ensure Bootstrap dark mode works
 - Plugin-generated form elements (e.g., `<select class="jr-search-form__filter-select">`) lack Bootstrap classes and need explicit dark mode styling via element selectors