Re-read the two trigger-walk pastes that had stopped reproducing

[iderex]

What was wrong and how I found it

The section docs/quality-parity.md carries for #62 discloses that its readings
were taken at 1fc6961 while the commands beside them resolve origin/main, so
each paste under them is a claim a reader re-runs. I re-ran all of them at
f59943dff615779fcb0bd7a35bad8514375faecf before writing anything. Two no
longer returned what stood under them.

The grep for workflow files with no push trigger:

git grep -L 'push:' origin/main -- .github/workflows/
origin/main:.github/workflows/dco.yml
origin/main:.github/workflows/dependency-review.yml
origin/main:.github/workflows/pull-request.yml
origin/main:.github/workflows/smoke.yml

Four, where the document pasted three and the sentence above it said three.

The loop over push triggers:

for f in $(git ls-tree --name-only origin/main .github/workflows/); do
  s=$(git show "origin/main:$f" | sed -n '/^  push:/{n;s/^ *//;p;}')
  [ -n "$s" ] && printf '%s %s\n' "$f" "$s"
done
.github/workflows/build.yml branches: [main]
.github/workflows/codeql.yml branches: [main]
.github/workflows/contexts.yml branches: [main]
.github/workflows/headless.yml branches: [main]
.github/workflows/invariants.yml branches: [main]
.github/workflows/prose.yml branches: [main]
.github/workflows/records.yml branches: [main]
.github/workflows/release.yml tags:
.github/workflows/scorecard.yml branches: [main]
.github/workflows/unicode-guard.yml branches: ["**"]
.github/workflows/zizmor.yml branches: [ main ]

Eleven lines, where the document pasted ten under a sentence saying every push
trigger in these files names the default branch except one.
.github/workflows/release.yml names no branch at all, so that sentence was
wrong rather than merely short.

Both differences have one cause: this board gained .github/workflows/release.yml
and .github/workflows/smoke.yml since the reading, and neither runs on a pull
request.

I re-ran the other three pastes in that section as well. The path-filter grep,
the branch grep over dependency-review.yml and the if: grep all reproduce
unchanged, and the sed -n '76,84p' paste of the zizmor upload condition still
returns the block it shows.

What this changes

The stale output is replaced by what the command returns, and each repair then
says which member is which kind rather than leaving the list to be counted. A
tag-triggered or release-triggered workflow joins both greps for a reason
neither section is about: it runs on neither a pull request nor a branch push,
so it cannot narrow a pull request and it cannot double a context. What is worth
reading either list for is a file that does run on a pull request appearing in
it.

That is the same separation the neighbouring branch-filter section already
carries, and the reason it is worth writing twice is that both lists grow for
the same reason and neither said so.

Means

Prose in the document the walk's result already lives in, edited in place. The
subject is a paste that stopped reproducing, so the artefact is the paragraph
around it and nothing else fits; no language, runtime or dependency is added,
and the existing prose suite is what judges the file.

What this does not reach

Nothing here observes a run. These are readings of trigger blocks in the
workflow files, which is what the section already bounds itself to. The
done-condition of #62 is unmoved by this: the required set is still empty and
the fork route is still unwalked, and what those wait on is written on the issue
rather than repeated here.

Gate

Run on this machine at the head of this branch:

go build ./cmd/... ./internal/...
go vet ./cmd/... ./internal/...
gofmt -l cmd internal
go test -count=1 ./cmd/... ./internal/...
go run ./cmd/lab check .

All green; gofmt -l printed nothing and lab check refused nothing.

No second person has read this change. That is stated rather than softened, and
the evidence above stands in place of one.