Add wordpress.editor-validate-blocks command (real wp.blocks.validateBlock on imported post content)

[chubes4]

Gap

There is no wp-codebox command that runs the real Gutenberg editor validation (wp.blocks.validateBlock) on post content. Consumers (e.g. the SSI fixture matrix) can only fall back to a PHP parse_blocks/serialize_blocks round-trip, which proves markup is well-formed but does NOT reproduce the editor's "this block contains unexpected or invalid content" check.

Verified during a matrix run investigation:

• grep validateBlock across packages/ → zero hits.
• Editor commands (packages/runtime-core/src/command-registry.ts): editor-canvas-probe, editor-open, editor-actions — none run JS validateBlock.
• editor-actions kinds (packages/runtime-playground/src/editor-actions.ts): open/waitForReady/insertBlock/selectBlock/savePost/inspectState — no generic JS-eval.
• captureEditorState/inspectState (editor-command-runners.ts) map getBlocks() to only {name, clientId, attributes} and drop block.isValid + block.validationIssues that Gutenberg already computes on load.

Ask

Add a wordpress.editor-validate-blocks command that:

• loads the block editor runtime (so block types are registered),
• accepts imported post content (and/or a post ID to open /wp-admin/post.php?post=<id>&action=edit),
• runs wp.blocks.parse + wp.blocks.validateBlock recursively over the blocks (incl. innerBlocks),
• emits { total_blocks, valid_blocks, invalid_blocks, validation_method: 'wp.blocks.validateBlock', validation_provider, results: [{ name, isValid, issues }] }.

(Alternative: extend captureEditorState/inspectState to include each block's isValid + validationIssues.) The dedicated command (above) is preferred — downstream collectors already parse exactly that shape.

Why

This is the only way to verify imported sites are genuinely editor-editable. Currently "editor validation" downstream opens an empty post-new.php and DOM-probes — it never validates imported content.