UI: Remove support for numeric multiplier on Box padding

[aduth]

What?

Updates @wordpress/ui's Box component to remove support for passing a number as a padding value, requiring consumers to use one of the available token values.

Extracted from #74001 (see #74001 (comment)).

Why?

See #73852 for context:

Since this component is a foundational component of the design system, it should aim to build on design tokens that form the basis of expressing spacing in a systems-based manner.

Testing Instructions

None of the current stories or tests provide coverage for this, likely because it was always considered an edge case, now completely unsupported.

You can still verify there is no impact to the rendering behavior of existing Storybook stories:

1. npm run storybook:start
2. Go to http://localhost:50240/?path=/docs/design-system-components-box--docs
3. Verify no regression in appearance of Box

[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: aduth <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: mirka <[email protected]>

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

[mirka]

By the way, was there any reason why the target type is not a union of valid strings?

[aduth]

I seem to recall some earlier consideration for using custom, extended targets, but now that you mention it, I'm not sure that's something we can or want to support.

[aduth]

I seem to recall some earlier consideration for using custom, extended targets, but now that you mention it, I'm not sure that's something we can or want to support.

More context: #72984 (comment)

Specifically this comment:

Part of the expectation here is that in how some components would use Box, they may introduce their own family of tokens, like a Card component using Box and having its own card-specific spacing tokens

Realistically, the way we're implementing tokens would mean that having tokens outside what exists today would still be something we'd want to include as a peer option of the existing surface, interactive options, and as such "a union of valid strings" can follow from that.

tl;dr: Yes, we should use a union 😄

[aduth]

Updated in 6cf0780. Separately I'd like to explore a way to better automate these types out of our existing token files.

[github-actions]

Flaky tests detected in 6cf0780.
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/20313708348
📝 Reported issues:

• [Flaky Test] should open and edit templates correctly when active_templates experiment is enabled #73752 in /test/e2e/specs/site-editor/template-id-format.spec.js