### Description When a DWT consumer overrides the primary color (e.g. DevGuard uses `--primary: #f9bd25`), the `.kern-btn--primary` button correctly uses that color in its normal and hover states. However, when the button becomes `disabled` or `[aria-disabled=true]`, it reverts to the hardcoded kern default blue (`#1A3DA5`) instead of the consumer's primary color. The root cause is a variable name mismatch in `@kern-ux/native/dist/kern.min.css`: ```css /* kern.css:1042 — disabled state */ .kern-btn--primary:disabled, .kern-btn--primary[disabled], .kern-btn--primary[aria-disabled=true] { background: var(--action-default, #1A3DA5); /* ← --action-default is never defined */ opacity: var(--action-state-opacity-disabled, 0.4); } ``` `--action-default` is never assigned anywhere in the CSS chain. Every other button rule in kern.css correctly uses `--kern-color-action-default`, which is bridged in `theme-bridge.css` to `var(--primary)`. The disabled rule is the only exception and always falls through to `#1A3DA5`. ### Steps to Reproduce 1. Use DWT with a custom `--primary` color that differs from `#1A3DA5` (e.g. `--primary: #f9bd25`) 2. Render a `<Button>` (primary variant) and trigger a state that disables it — e.g. submit the feedback form and observe the button during the loading/network request phase 3. Observe the button background color while it is disabled ### Expected Behavior The disabled button retains the consumer's `--primary` color (at reduced opacity via `--action-state-opacity-disabled: 0.4`). ### Actual Behavior The disabled button background snaps to `#1A3DA5` (the kern default blue) because `--action-default` is undefined and the fallback value is always used. On fast connections this is a brief flash; on slow connections the wrong color is visible for the entire duration of the loading state.