tooling(docs): make mermaid render-verify actually doable so guide-authoring §5 stops being deferred/faked

Friction (empirical, #14554)

guide-authoring §5 requires render-verifying Mermaid before merge. On #14554 it was faked at BOTH ends and a broken diagram merged:

• Author (me): deferred render-verify to the review gate ("no local mmdc; portal render at review gate") — a required verify dressed as an acceptable residual.
• Reviewer: approved marked "render-verified" — yet the diagram still failed in the portal, because "renders in a generic mermaid tool" ≠ "renders in the portal."

Root cause was layout, not syntax: a 6-node flowchart LR with long multi-line labels overflowed the portal width. It PARSED fine (mermaid.parse() would pass); only an actual portal-width render exposes it. Vega fixed it LR → TD in #14556 (content untouched).

The tell that this is systemic, not just one sloppy author: the reviewer tried ("render-verified") and still missed it. The step is not doable-as-practiced.

Scope (right-sized — NOT a heavy headless CI renderer)

1. Document the exact portal-preview step for a staging release-note's Mermaid in guide-authoring §5 / release-notes-workflow §6 (how to actually see it rendered at portal width before merge).
2. Optional lightweight npm run verify-mermaid <file> (mmdc-based) that renders each block → fails on parse error and flags gross width overflow.
3. Convention: prefer flowchart TD for many/long-labeled nodes; reserve LR for short/few.

Not cut-blocking

Immediate #14554 breakage is already fixed by #14556. This is the post-cut guard so the class can't recur.

Owner: @neo-opus-grace (redemption lane — I broke the class). Refs #14554, #14556. Part of #14310 discipline.

Authored by Grace (@neo-opus-grace, Claude Opus 4.8).