Theme: Add disabled variants for brand and error interactive color tokens

[ciampo]

What?

Addresses point T-M5 of #77462.

Adds disabled variants for the brand and error tones across the interactive color tokens (background, foreground, stroke), for parity with the existing neutral disabled tokens, and adopts them in the Button, AlertDialog, and Select/Autocomplete/Combobox components.

New tokens

background.interactive

• --wpds-color-background-interactive-brand-strong-disabled
• --wpds-color-background-interactive-brand-weak-disabled
• --wpds-color-background-interactive-error-disabled
• --wpds-color-background-interactive-error-strong-disabled
• --wpds-color-background-interactive-error-weak-disabled

foreground.interactive

• --wpds-color-foreground-interactive-brand-disabled
• --wpds-color-foreground-interactive-brand-strong-disabled
• --wpds-color-foreground-interactive-error-disabled
• --wpds-color-foreground-interactive-error-strong-disabled

stroke.interactive

• --wpds-color-stroke-interactive-brand-disabled
• --wpds-color-stroke-interactive-error-disabled

Why?

disabled variants existed only for the neutral tone, so a disabled brand/error element had to borrow the neutral token. These parity tokens let each tone reference its own disabled state. The values match the corresponding neutral disabled values, so there is no visual change. The stroke set mirrors neutral, which exposes only a normal-emphasis disabled stroke (no strong-emphasis variant).

How?

• Added the token definitions in `packages/theme/tokens/color.json` and made the disabled token descriptions tone-specific.
• Regenerated the prebuilt artifacts via `npm run build` (CSS, JS allow-list/fallbacks, TS types, `docs/tokens.md`).
• Adopted the new tokens in `@wordpress/ui` (`Button`, `AlertDialog`, and disabled `Select`/`Autocomplete`/`Combobox` list items).

Testing Instructions

• `npm run build` in `packages/theme` produces no diff against the committed prebuilt files.
• Disabled `brand`/`error` buttons and the `AlertDialog` destructive action render identically to before (no visual change).

[github-actions]

Size Change: +151 B (0%)

Total Size: 8.58 MB

📦 View Changed

Filename	Size	Change
build/modules/boot/index.min.js	52.8 kB	+34 B (+0.06%)
build/modules/content-types/index.min.js	159 kB	+14 B (+0.01%)
build/scripts/editor/index.min.js	473 kB	+16 B (0%)
build/scripts/theme/index.min.js	22.3 kB	+87 B (+0.39%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 8ee8bfc.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27578962689
📝 Reported issues:

• [Flaky Test] shouldn't conflict with server-side autosave #78706 in /test/e2e/specs/editor/various/autosave.spec.js
• [Flaky Test] shows post-locked modal when document size limit is exceeded #78753 in /test/e2e/specs/editor/collaboration/http-only/collaboration-document-size-lock.spec.ts

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[aduth]

LGTM 👍 Importantly I think this detaches semantics from styling in a way that's true to how we structure tokens and avoids tying ourselves incidentally to "gray" as disabled in case we want to change course on that styling in the future.

[aduth]

This tokens naming consistency work had me thinking again about the AI agent confusion I mentioned in #78438 (comment). Is there a similar case to be made about adding a "duplicate" var(--wpds-color-foreground-content-brand); for completeness' sake?

[ciampo]

This tokens naming consistency work had me thinking again about the AI agent confusion I mentioned in #78438 (comment). Is there a similar case to be made about adding a "duplicate" var(--wpds-color-foreground-content-brand); for completeness' sake?

content tokens are for non-interactive UI, meaning they can't be disabled

[aduth]

This tokens naming consistency work had me thinking again about the AI agent confusion I mentioned in #78438 (comment). Is there a similar case to be made about adding a "duplicate" var(--wpds-color-foreground-content-brand); for completeness' sake?

content tokens are for non-interactive UI, meaning they can't be disabled

I was referring to the neutral vs. brand completeness, not strictly talking about disabled.

[ciampo]

This tokens naming consistency work had me thinking again about the AI agent confusion I mentioned in #78438 (comment). Is there a similar case to be made about adding a "duplicate" var(--wpds-color-foreground-content-brand); for completeness' sake?

content tokens are for non-interactive UI, meaning they can't be disabled

I was referring to the neutral vs. brand completeness, not strictly talking about disabled.

My bad, I read disabled instead of duplicate 😅

In any case, the lack of the brand tone in color-foreground-content is currently by design, since the DS doesn't contemplate non-interactive text in the brand color, and therefore we omitted those tokens.