Block editor: ship first-party TypeScript types for @wordpress/block-editor

What problem does this address?

@wordpress/block-editor has no first-party TypeScript types that a consumer can resolve. Its package.json (v17.1.0, current latest) exposes only runtime entry points:

"exports": {
  ".": { "import": "./build-module/index.mjs", "require": "./build/index.cjs" },
  "./package.json": "./package.json",
  "./build-style/*": "./build-style/*"
}

There is no top-level "types" field and no types condition in exports["."], so under moduleResolution: "bundler"/"node16"/"nodenext" TypeScript cannot find types for import * as blockEditor from '@wordpress/block-editor'. Consumers are pushed to the community-maintained DefinitelyTyped stub @types/wordpress__block-editor instead.

This is the same class of issue already fixed for @wordpress/preferences in #73275 / #73276. Unlike preferences, though, @wordpress/block-editor's entry point is src/index.js and only a subset of the package is typechecked, so build-types/ currently ships partial declarations (components/, utils/, lock-unlock.d.ts) with no entry build-types/index.d.ts — a plain types addition alone would not be enough here.

What is your proposed solution?

Ship first-party types for @wordpress/block-editor so consumers can drop @types/wordpress__block-editor:

1. Generate a public-API entry declaration (build-types/index.d.ts) for the package — this is the larger part, since the entry is currently untyped JS.
2. Once emitted, expose it the same way #73276 did for preferences:
   diff复制

     "exports": {
       ".": {
   +     "types": "./build-types/index.d.ts",
         "import": "./build-module/index.mjs",
         "require": "./build/index.cjs"
       },

   and/or add a top-level "types": "build-types" (matching @wordpress/blocks).
3. Ideally validate the emitted declarations with @arethetypeswrong/cli.

Even an incrementally-typed entry declaration would let downstream TypeScript projects stop depending on the DefinitelyTyped stub.