Fail closed on the two publish-post preflights that only warned

[jasperf]

Fixes #216 and #217. Both are the same shape of problem: the preflight already knew enough to prevent a bad publish and let it through anyway, and every verification downstream reported success.

Self-closing custom blocks are now refused (#216)

The one-liner Gutenberg's inserter produces (<!-- wp:imagewize/cta {...} /-->) saves an empty block when written through WP-CLI — the InnerBlocks template is hydrated client-side on insert, so nothing expands it server-side. Nothing errors, the block is missing from the rendered post, and a post_content diff shows nothing. Two posts on imagewize.com shipped with an empty CTA block in four days.

verify-post has always treated this as a hard FAIL, so the tool waved the draft through and then failed it afterwards, at the one point the mistake could no longer be prevented cheaply.

• publishPost.ts and publish-post.sh now throw / exit 1, matching the near-empty-body check directly above it.
• The message names the offending blocks, which verify-post already did and publish-post didn't.
• Both entry points use verify-post's pattern now, so the attribute-less form (<!-- wp:ns/block /-->) is caught too — the publish-side regex previously required attributes.
• --allow-self-closing-blocks / allowSelfClosingBlocks: true publishes anyway, for a genuinely dynamic, server-rendered block; it downgrades to a warning rather than disabling the check.

Secondary: the MCP tool gained the wp:nynaeve/ bad-block prefix publish-post.sh already had. nynaeve is a block category, not a namespace — every block is imagewize/* — so any wp:nynaeve/x is a typo. The list is now a named constant so the two entry points can be compared at a glance.

imageAttachmentId writes the Article schema image (#217)

injectArticleImage() sat inside the imagePath branch, so an attachment ID set _thumbnail_id and nothing else, even though the two options are documented as interchangeable.

A post first published with imagePath carries an image field the local draft never had — wp-ops added it at publish time. A later content-only update passing imageAttachmentId (to avoid a duplicate attachment) therefore republished it without one, and every check passed: publish_post compares source bytes to stored bytes and the source was already missing it; verify_post counts JSON-LD blocks and the count never changed.

The URL is now resolved with wp_get_attachment_url() and both options end at the same injection. A non-existent attachment ID is an error rather than a bogus _thumbnail_id, and the Featured image: output line carries a URL either way.

An update that drops live Article schema fields is refused (#217)

Both tools verify that what was sent is what landed. Neither noticed that what was sent was poorer than what it replaced — and on an update, the previous state is the only state nobody looks at.

Since a draft is written before wp-ops enriches the post, re-publishing it strips that enrichment back off. It happened to image; datePublished, author and publisher are strippable exactly the same way.

publish-post now reads the live post before writing and compares its Article JSON-LD keys against the draft's, refusing the update and listing what would be dropped. --allow-schema-regression / allowSchemaRegression: true overrides. The MCP tool checks in preflight so dryRun: true reports it before anything is written; the shell script checks inside the PHP worker, the first point at which a per-target run can see the target at all.

Also

• go/internal/catalog/catalog.json regenerated for the two new flags.
• mcp-server/README.md and the publish_post tool description updated.
• CHANGELOG entry for 5.19.0.

Verification

tsc --noEmit, npm run build, bash -n publish-post.sh, go test ./... — all pass. The generated PHP worker was linted with php -l, and the PHP and TypeScript implementations of Article-key extraction and self-closing block-name extraction were checked against the same fixtures to confirm they agree. No live publish was exercised; that needs a real site.