No gate checks a §-citation against the clause the vendored specification gives it

[justin13888]

Nothing in this repository checks that a §X.Y citation names the clause it claims. The specs are
vendored under references/, the clause headings are extractable from them, and the citations are
greppable — but the two are only ever compared by a human reading a diff.

Three instances are already on the record, in two crates:

• gamut-png: six files cite tRNS as §11.3.2.1, which the vendored spec gives to cHRM #604 — gamut-png: six files cite tRNS as §11.3.2.1, which the vendored spec gives to
  cHRM.
• PR feat(icc): built-in profile constructors and CICP → profile #542 (gamut-icc, issue gamut-icc/gamut-color: built-in profile constructors + CICP -> profile #424): builtin.rs cited §10.7 for cicpType; §10.7 is
  dataType. Caught in review, round 3.
• PR feat(icc): built-in profile constructors and CICP → profile #542, round 4: the same file cited §9.2.10 for the MatrixColumn tags and §9.2.35
  for chad; those clauses are BToD1Tag and metadataTag. Caught in review, round 5 — the round
  that repaired the first one also shipped a completeness claim ("every other citation in the
  module checks out") that was itself false.

The last one is the argument for a gate rather than more care: a hand audit of a citation set
produces a claim of completeness that no check backs.

Shape of the check

Mechanical, and cheap:

1. Extract a clause index from the vendored PDF — number → heading title.
2. Grep the crate for §[0-9.]+.
3. For each citation, assert the clause exists, and (where the citing line names a tag, type or
   field) that the heading title contains that name.

Executed by hand against references/icc/icc.1-2022-05.pdf for PR #542 this resolved all 58
distinct citations in crates/gamut-icc/ in one pass and found exactly the two wrong ones. The
same pass over gamut-png would have found #604.

What blocks it today

The extraction step needs a PDF-to-text tool, and none is provisioned in mise.toml. The
tool used above (pdftotext, poppler) happened to be present on the machine, which is exactly the
kind of ambient dependency a gate must not have. Wiring this means adding a pinned extractor to
[tools] first, and deciding whether the clause index is regenerated per run or vendored beside
each spec as a checked-in clauses.tsv that a separate task refreshes.

Two wrinkles the ICC pass surfaced

• A spec's own numbering can disagree with itself. ICC.1:2022 §8.4.3 cross-references
  redMatrixColumnTag as 9.2.44 and greenMatrixColumnTag as 9.2.30, while the clause headings
  number them 9.2.46 and 9.2.31. Both are in the same document. A gate has to fix which numbering
  it checks against (the headings are the defensible choice) and tolerate the other.
• Not every citation is to the crate's primary spec. gamut-icc cites ICC.1:2001-04
  §6.5.17 for textDescriptionType, correctly, from a file whose other citations are all
  ICC.1:2022. The citation syntax carries no edition, so either the gate reads the edition from the
  citing line's prose or the syntax gains one.

Relation to #549

#549 ("No gate compiles a README code block or fails on a broken rustdoc link") is the same
absence one axis over: a documentation claim no check can see. This one is about claims that point
at a vendored specification rather than at code. They may want to be one task or two; that is part
of what this issue decides.