four consumers explain the release path's contents grant with an API call that never happens

[CarlAllenn]

Defect

The false claim #850 removes from workflow-templates/release.yml also
lives in all four consumers, in their own tracked copies, and nothing
propagates the canon's fix to them.

Measured live 2026-08-24 via gh api repos/monumental-archive/<repo>/contents/.github/workflows/release.yml:

repo	line	text
edtf	54	contents: read # the version derivation's history read, and the checkout
iiif-server	54	same
release-lab	49	same
stele	54	same

edtf, iiif-server and stele also carry the stub's surrounding prose —
"stele derive reads the repository's commits through the GitHub API, so
the shared workflow needs this". release-lab's wording differs ("the
shared workflow needs this to read the commits it derives the version
from") and asserts the same mechanism.

The claim is false at the belt-pinned stele: stele derive release-plan
reads the LOCAL history that fetch-depth: 0 supplies and makes no API
call — the measurement is in #850 and is not repeated here. The real
readers are the checkout and generate-pgrx-upgrade.sh's authenticated
gh release reads.

Why the canon's fix does not reach them. The workflow templates are
scaffold: MAINTENANCE.md records that a stub is "copied once, never
consumed live", so a template improvement reaches no existing repo and
nothing compares a repo's copy to it. This is the drift shape
docs/tooling-verdicts.md already names for scaffold generally — the
same reason release-lab was missing eight scaffold files for five
releases. Here it is a comment rather than a control, so nothing is
enforced wrongly; four production repos simply explain a live permission
grant with a mechanism a reader can check and disprove.

Not a level, and not an outage: the contents: read line each comment
sits above is correct and stays.

Decided build

Not decided — this issue exists to make the choice once rather than four
times. The options, so neither is re-derived:

• Four commits. Correct each consumer's comment to the the release path's contents grant is under-declared in the tag job and explained by an API call that never happens #850 wording,
  one repo at a time, alongside their next canon pin bump. Cheap, and it
  leaves the same drift free to recur at the next stub edit.
• State the boundary instead. Accept that stub prose diverges by
  design once copied, and stop writing mechanism claims into stubs that
  a repo will carry unexamined — keep the stub comment to what the line
  does, and let the reasoning live in the canon's own workflow where it
  is maintained.

Worth deciding together with #777, which asks the adjacent question about
scaffold/ never being built from.

Canon consequence

None to the canon: #850 already corrects the template. The consequence is
to the four consumer repos, and only to a comment each of them carries.

Done when

• the four consumer copies either say something true about why
  contents: read is granted, or say nothing about the mechanism
• whichever is chosen is recorded where the next stub author reads it, so
  the next mechanism claim does not enter a stub the same way

Sequencing

Independent; nothing is failing. Land after #850 (PR #883), whose wording
is the model for option 1. Refs #850, #849, #741, #698, #777.

Found while verifying that #850's callee-side grant sat inside every
caller's ceiling — the consumer files had to be read anyway.

[CarlAllenn]

Orchestrator decision (delegated, 2026-08-24), replacing the two options in the Decided build above:

Decided as the RULE, not as four comment fixes. A stub carries
obligations and interfaces — what the caller must grant, what it must
pass, what it gets back. It does not carry mechanism claims about the
callee's internals. The callee's own comments are the single home for
those, because that is where the mechanism lives and where a change to it
is made. A claim copied out of that home rots by construction: nothing
consumes a stub live, nothing compares a copy to it, and no check exists
that could. This issue measured that rot at 4-for-4 on the first stub
prose anyone went looking at.

That makes option 2 the decision, and it generalises past this comment:
the fix is not "correct these four sentences" but "stop writing sentences
of this kind into stubs at all".

Rejected, recorded so it is not re-proposed: the four-repo comment
fan-out as a lane of its own. It treats the symptom, costs four PRs
against production repos for a comment, and leaves the next stub author
free to write the next mechanism claim — which the next reader would then
be asked to fan out again.

How the four existing copies get corrected: each rides its own repo's
next canon pin-bump PR, where the file is already open and the diff
already has a reason to exist. No fan-out, no lane tonight.

Status: this stays open and queued. The rule needs a home a stub
author will actually meet — a line in the scaffold documentation, or a
lint over workflow-templates/ prose if one can be stated without
guessing at intent — and that home has not been chosen. Worth deciding
together with #777, which asks the adjacent question about scaffold/
never being built from.