Say which contexts arrive on which pull requests

[iderex]

Closes nothing. It moves #62, and the two clauses that issue is still open on
are named at the bottom.

What this changes

docs/quality-parity.md gains a section next to the required set saying which
contexts arrive, on which pull requests, and which of this board's strings each
of two table rows is about. The two rows for CodeQL and
Audit workflows (zizmor) gain one sentence each pointing at it.

Two facts drive it, both measured rather than reasoned about.

A code-scanning upload creates a check run of its own, so CodeQL and zizmor
are names beside the job names CodeQL (go) and Audit workflows (zizmor). The
upload in .github/workflows/zizmor.yml is conditional and the step that fails
on findings is not, so on a pull request running with a read-only token the job
arrives and reports while the upload-derived context never appears. That is
measured on a pull request open on this board today rather than read off the
condition. It decides one name: zizmor cannot go into the required set,
because requiring it would hold open every pull request the condition excludes
with nothing on the pull request saying why.

The command this document hands #26 to assemble the required set from resolves
origin/main, and a commit on the default branch is reached by a push. Three
workflows here carry no push trigger, so that command omits three contexts every
pull request reports and offers one that no pull request can report. Both
directions of the difference are quoted from comm over the two sets.

The means

Prose in the document the issue names as the place to write the result, because
the artefact is a reading of a live setting rather than a guard. Nothing here is
a rule a machine could refuse: every claim is instead quoted with the command
that produced it, and the section says at the end what it did not settle.

Evidence

Run at c9780aa, from this checkout:

go build ./cmd/... ./internal/...
go vet ./cmd/... ./internal/...
gofmt -l cmd internal
(no output)
go test -count=1 ./cmd/... ./internal/...
ok  	github.com/Flowfin/lab/cmd/contexts
ok  	github.com/Flowfin/lab/cmd/lab
ok  	github.com/Flowfin/lab/cmd/notices
ok  	github.com/Flowfin/lab/cmd/pullrequest
ok  	github.com/Flowfin/lab/internal/check
ok  	github.com/Flowfin/lab/internal/contexts
ok  	github.com/Flowfin/lab/internal/hardware
ok  	github.com/Flowfin/lab/internal/invariants
ok  	github.com/Flowfin/lab/internal/notices
ok  	github.com/Flowfin/lab/internal/prose
ok  	github.com/Flowfin/lab/internal/pullrequest

go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
18 decision records read
0 refused

The timing lines the suite and the runner also print are cut, and nothing else
is.

Every command quoted inside the new section was run against origin/main or
against the platform before it was written down, and each one is written so a
reader can re-run it.

What this does not settle

The fork route is unwalked. No pull request from a fork has been opened here,
and the condition measured has two arms of which only the second was reached, so
nothing in this change says what a fork produces. CodeQL did arrive on the
read-only-token pull request measured, so it gains no verdict here either.

The required set is empty, so nothing in this change reports a required context
that failed to arrive. It is about which names a set could hold.

#62 therefore stays open on its first clause, which needs the set #26 assembles,
and on the fork half of its second.

No second person has read this change. The evidence above stands in place of
one.