Ensure changeset PRs produce correct and minimal release automation output.

Apply these rules before submitting:

• Create changesets only for user/release-relevant changes. If it’s documentation-only, do not add a changeset.
• Scope packages precisely. A changeset header should include only the packages that are actually affected.
• Split multi-package changes when entries should land in separate release notes. If one change affects two packages independently, use separate changeset files rather than combining messages in one.
• Choose the semver level based on user impact:
  • major: reserved for breaking changes.
  • patch: bug fixes / no user-facing behavior change.
  • minor: non-breaking new functionality/improvements that affect users.
  • Avoid using non-standard bump labels (e.g., chore) when major/minor/patch is expected.

Example (correct semver selection + scoped header):

---
'mermaid': patch
---
fix: Correct diagram rendering regression

Example (split multi-package change into separate files):

• File A: bump only @mermaid-js/examples
• File B: bump only mermaid with each file containing only its relevant release-note text and semver decision.