ci: gate CITATION.cff version against pyproject

[musharna]

Why

CITATION.cff records the release version in a second place, independent of
pyproject.toml, and nothing kept the two in agreement.

This is not hypothetical — it has already happened twice:

• ghostcite shipped v0.5.0 while its CITATION.cff still said 0.4.0.
• plant-genomics-mcp drifted to 1.19.3 vs 1.19.4 within two hours of the
  file being added, when v1.19.4 was cut.

Stale citation metadata is worse than none. It is machine-readable, GitHub renders it in
the Cite this repository panel, and Zenodo mints DOI records from it — so a wrong
version propagates into other people's bibliographies, where nobody will ever check it
against the tag.

What

Adds .github/workflows/citation.yml: on every PR and push to main, fail if
CITATION.cff's version: does not equal pyproject.toml's version.

This deliberately mirrors the existing "tag matches pyproject version" release gate
(release.yml), which exists for the same reason one layer down — refusing to publish a
mislabeled artifact. Same invariant, same failure mode, enforced earlier and on every change.

Self-contained new workflow rather than an edit to existing CI, so it cannot affect the
current test matrix.

Verification

The check was run against real repository data before being proposed, in both directions:

positive — jobd (genuinely in sync)
  pyproject.toml : 0.5.35
  CITATION.cff   : 0.5.35
  in sync                                        exit=0

negative — plant-genomics-mcp (the real, live drift)
  pyproject.toml : 1.19.4
  CITATION.cff   : 1.19.3
  ::error::CITATION.cff says 1.19.3 but pyproject.toml says 1.19.4 …   exit=1

The failing case is real drift, not a synthetic fixture — so the gate is known to fire on
the exact condition it exists to catch, not merely to pass when things are fine.

🤖 Generated with Claude Code