Name the collation for reference-link definition sort order

[ptr727]

AGENTS.md "Documentation Style Conventions > Markdown" says reference-link definitions are "alphabetized by reference name". That is ambiguous wherever one label is a prefix of another, and the two readings disagree:

• Sorting the full definition line, which is what plain sort does, puts [agents-write-safety] before [agents], because - (0x2D) sorts before ] (0x5D).
• Sorting the bare label puts [agents] first.

The definition blocks in ESPHome-Config are consistently the first form and pass LC_ALL=C sort -c on every group. Copilot reviewed a PR touching one of those blocks and reported the order as an alphabetization defect, asking for a re-sort. Applying it would reorder [agents-write-safety] / [agents] and simultaneously break [rgb-led-status-template] / [rgb-led-status], since no single bare-label order satisfies both prefix pairs.

Naming the collation in the rule would settle it, for example "alphabetized by the full definition line (plain sort)". Whichever form is chosen, being explicit stops the comment recurring on every PR that touches a definition block.

Instance: ptr727/ESPHome-Config#80.

[ptr727]

Fixed in e848a4d on develop (#586).

GOVERNANCE.md "Documentation Style Conventions > Markdown" now names the sort key as the reference name alone, the text inside the brackets, never the whole definition line, so a shorter name sorts above one it prefixes ([governance] above [governance-branching-model]). It also records the trap that produced the review comment: a plain sort -c over the block compares the line, so it passes on the inverted order, and a block can be mechanically "sorted" and still be wrong.

The bare label is the reading rather than the full line, because it is what the rule's own wording already said and what the corpus already does. All twelve reference-definition groups in this repository sort by the bare label and none by the line, so the line reading would have meant re-sorting README.md, AUDIT.md, CODESTYLE.md, STANDUP.md, TODO.md, and five more against a rule that never asked for it.

spec/readme-structure.md carries the same key, since a repository reading the spec without the governance file would otherwise still be guessing. Two <!-- Repo --> blocks, in WORKFLOW.md and docs/repo-config-carry.md, were ordered by neither collation and are fixed, so the canonical satisfies the rule it states.

Closed by hand rather than by keyword, because the merge landed on develop and a closing keyword fires only on the default branch.

Two follow-ons: GOVERNANCE.md is verbatim-carried, so this adds to the fleet re-vendor already owed, and the definition blocks in the instance repository are ordered by the full line, so they need a re-sort under this rule.