Validate .changeset/*.md frontmatter via md-frontmatter/schema

[gtbuchanan]

@gtbuchanan/eslint-plugin-md-frontmatter (introduced in #67) was extracted as a generic Markdown frontmatter validator specifically so it could serve consumers other than Agent Skills. The most concrete second consumer in this repo is .changeset/*.md.

Background

Each changeset file has YAML frontmatter declaring affected packages and bump types:

---
'@gtbuchanan/eslint-config': minor
---

Fix rule conflict

Today, malformed changesets (wrong bump type, unknown package name, malformed frontmatter) only fail at changeset version time — usually in CI on the version-PR. Linting them at edit time would catch issues immediately.

Proposal

Wire md-frontmatter/schema into eslint-config for .changeset/*.md files with a schema that validates:

• frontmatter is an object whose values are exactly 'major' | 'minor' | 'patch' | 'none'
• frontmatter keys are valid workspace package names (resolved at config-build time from pnpm-workspace.yaml + each package's package.json)

Open questions

• Workspace-derived enum: the schema's allowed package-name keys should reflect the actual workspace, not be hardcoded. Means the schema is computed at config build time, not a static .json file. Probably lives in eslint-config/src/plugins/changeset.ts rather than as a publishable artifact.
• Empty changesets: pnpm changeset --empty produces a frontmatter with no keys. Schema should allow this (empty object).
• Interaction with markdownlint plugin block: changesets are already exempt from markdownlint (.changeset/** is in the ignores). Need to make sure the schema rule is NOT exempt from this glob.

Scope

Small: ~30 LOC config block + a handful of e2e cases mirroring the SKILL.md pattern.