Fix: repair genuinely-invalid blocks in canonicalize()

[saarnilauri]

Problem

canonicalize() (the fix command) produces its output with
serialize(parse(markup)). This canonicalizes near-misses attribute order,
whitespace, generated classes, but it does not repair a block whose stored
HTML actually fails validation. WordPress's serializer re-emits a block's
originalContent verbatim when isValid === false, so a genuinely-invalid
block round-trips unchanged and fix just reports it invalid.

Fix

Before serializing, rebuild invalid registered blocks from their parsed
attributes via createBlock(), so each block's save() re-runs and emits valid
markup. Valid blocks keep their parsed form (with any repaired descendants), and
unregistered blocks (core/missing, custom blocks) pass through untouched. This
is the same technique the token-repair path already uses in tokens/apply.ts
after it mutates attributes, wrapped in withMutedWordPressConsole for the same
reason.

Scope note

Blocks whose invalidity is covered by a deprecation (e.g. a heading missing
wp-block-heading) are already repaired by parse()'s migration and are
unaffected. This targets the rest, near-miss structures with no matching
deprecation, such as an image without its <figure> wrapper or a button
without wp-block-button__link. Rebuilding regenerates a block's inner markup
from save(), so it's applied only to blocks that were already invalid.

Tests

• repairs a genuinely-invalid block by rebuilding from parsed attributes —
  an image without <figure> becomes valid (wp-block-image, src preserved).
• leaves unregistered blocks untouched while repairing invalid core blocks —
  a custom block round-trips verbatim while an invalid core image is repaired.

Both fail on main and pass with this change. Full suite green (198 tests),
typecheck clean.

Use of AI

The code changes were created with AI agent, the changes reviewed by me.