fix: keep headless Gutenberg registry aligned with block editor

[mattheu]

This PR fixes two separate defects found while investigating "block-runner breaks in real consumer projects" — a runtime resolution bug and an install-time peer-dependency pinning defect. Kept together since they were found together, but they're independent fixes.

Fix 1: keep headless Gutenberg registry aligned with block editor

Fixes author() failing in consumers that install a newer top-level @wordpress/blocks. The failure was reported as conversion failed: Cannot read properties of undefined (reading 'align') at stage: intermediate, phase: source-analysis.

Root cause

The headless bootstrap loaded @wordpress/blocks relative to block-runner, while core block save functions loaded their @wordpress/block-editor helpers through the block-library dependency tree. npm can split those into separate package instances when a consumer also has a newer top-level @wordpress/blocks, leaving the save hook with an undefined attributes object.

Fix

Resolve the blocks registry relative to the block editor used by the resolved block library, so block creation, serialisation, and save hooks use the same Gutenberg runtime.

Regression coverage

Extends the packed-package boundary test with a fresh consumer that installs @wordpress/blocks@16.0.0 alongside the packed tarball and verifies author() returns a canonical plan.

Verified with npm run typecheck, npm run test:package, the headless smoke test, and the documented feature-note example against a freshly packed local build.

Fix 2: loosen exact-pinned optional peer dependencies to caret ranges

Fixes a plain npm install block-runner failing with ERESOLVE in consumer projects that already depend on the same optional proof-command peers at a different (compatible) version — e.g. a @wordpress/scripts theme that already has its own @playwright/test and @wordpress/e2e-test-utils-playwright for unrelated e2e tests.

Root cause

All six proof-command peerDependencies (@playwright/test, @wordpress/e2e-test-utils-playwright, @wordpress/env, axe-core, pixelmatch, pngjs) were exact-pinned despite being marked optional via peerDependenciesMeta. npm 7+ refuses to resolve an exact-pinned peer against an incompatible version already present in the consumer's tree, even when the peer is optional. The only workarounds were --legacy-peer-deps (which disables peer-conflict checking for the entire install, not just this package — in the real case this also silently let an incompatible ESLint version through, breaking eslint with Cannot find module 'eslint') or --force.

Fix

Publish caret ranges (e.g. ^1.61.1 instead of 1.61.1) for the six optional proof peers, so a compatible version already in the consumer's tree resolves cleanly. The proof command's own internal tooling versions stay exact-pinned via devDependencies for reproducible real-browser proof runs — src/proof/runner.ts and scripts/package-boundary-check.mjs now read those exact versions from devDependencies directly instead of peerDependencies.

Verification

• Reproduced the failure: packed the pre-fix build, installed it into a consumer with @playwright/test@^1.62.1 and @wordpress/e2e-test-utils-playwright@^1.54.0 already present — plain npm install failed with ERESOLVE on @playwright/test@1.61.1 as described above.
• Confirmed the fix: repacked with the caret ranges, same consumer, plain npm install (no --legacy-peer-deps, no --force, no overrides) now succeeds cleanly — @playwright/test@1.63.0 and @wordpress/e2e-test-utils-playwright@1.54.0 resolve and dedupe against block-runner's peer ranges.
• npm run typecheck, npm run build, npm test (706 passed, 4 skipped, 0 failed), and the targeted packaging boundary test all pass against the fixed tree.

[mattheu]

Closing in favour of a simpler fix: bumping block-runner's own bundled @wordpress/blocks (and the paired @wordpress/block-editor / @wordpress/block-library) to a current version, rather than adding a runtime resolution-consistency shim. The shim genuinely fixes the class of bug (any future consumer version mismatch), but the team decided the added internal complexity isn't worth it versus just tracking a current WordPress version directly — with the trade-off understood that a future WP major bump on the consumer side could reintroduce the same failure mode until block-runner's own pin catches up again. Follow-up PR incoming with the version bump.