design-system-mcp: Remove Storybook dependency in TypeScript types

[aduth]

What?

Related: #79095 (comment)

Updates @wordpress/design-system-mcp to remove storybook as a dependency.

Why?

Fixes an issue where built TypeScript types have an implicit dependency on storybook, but it isn't defined as a dependency by the package. Defining storybook as a dependency of the MCP server is not acceptable because it is a large dependency tree, and the MCP server relies on recurring updates / installs to keep itself up to date (via npx).

How?

Replaces the TypeScript type sourced from storybook package internals with a duplicate copy.

The motivation for using the internal types is explained in #78185 (comment), essentially as a way to provide some awareness when the internal shape changes, since the MCP relies on the shape of the component manifest. However, as explained later in the same thread, we have additional assurances for this through a separate validation step added in 8f53c41. Maintaining a duplicate type is some additional overhead for us, but it's much better than making storybook a dependency.

Testing Instructions

Verify npm run build passes, which includes TypeScript type-checking.

Observe there are no references to storybook package in packages/design-system-mcp/build-types after build.

Observe that the "Validate manifest matches design-system-mcp contract" CI check on this pull request passes.

Use of AI Tools

No AI was used.

[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 <aduth@git.wordpress.org>
Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>

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

[github-actions]

Size Change: 0 B

Total Size: 8.59 MB

_{compressed-size-action}

[github-actions]

Flaky tests detected in 0379bfe.
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/27433645378
📝 Reported issues:

• [Flaky Test] Should save the changes #78689 in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js

[manzoorwanijk]

Fixes the problem. Thanks

npx --yes @mawesome/dependency-audit packages/design-system-mcp
trunk	This PR

[ciampo]

Given that our types can now go out of sync with Storybook's first-party types, do have a way to know if/when we should update our types? In other words, should we strengthen runtime checks to validate the object structure received from Storybook APIs?

[manzoorwanijk]

Since the type gets used in the config etc. it should be caught if there is a major upstream change.

[aduth]

I think we do lose some assurances here, since the other usage of Storybook internal types doesn't exercise the ComponentManifest type that we rely on so heavily in the MCP package. But also, a lot of what we depend on comes through the reactDocgen types that aren't part of those internal types anyways.

We still have the CI check for ensuring that the manifest is parseable. This should be enough to catch an issue if a Storybook upgrade would regress the ability to retrieve component information.