Point the signature row at the record that answers it

[iderex]

Refs #55

What this changes

docs/quality-parity.md, one section: ### The rule neither board carries.

It said the signature question is "an entry on issue #46, which is open". That
issue is closed and the entry is answered, so the section now names the record
that holds the answer, docs/decisions/0023-signed-commits-on-the-default-branch.md,
alongside the issue it still names for the leg of #55 that asks for it. It also
pastes the four live states it rests on rather than asserting them: the rule
types on both boards, the state of #46, and the state of the key-custody question I keep
elsewhere, which is the condition 0023 makes itself effective on.

No path leaves the tree. The change is 44 insertions and 5 deletions inside one
file.

The means is prose in the document that already carries this walk, because the
subject is a claim in that document about another artefact and the repair has to
land where a reader meets the claim. A new file would leave the wrong sentence
where it is, and a decision record would be the wrong register: 0023 is the
decision and this is the walk pointing at it.

What failure it prevents

A reader following the row to an open issue concludes the question is unsettled,
and then either waits for an answer that exists or takes it a second time. It is
decided, effective as the keys land, and recorded. Record 0023 names this
document among the things it applies to, so the pointer is owed here rather than
merely tidy.

The second half prevents the opposite error, which arrives with the repair. A
rule that has been decided is not a rule that is configured, and a section that
now names a decision could be read as a merge gate standing here today. It does
not stand: required_signatures is absent from both rulesets, 0023 says of
itself that nothing in this tree refuses an unsigned commit, and the condition
that makes it effective is open on another board. All three are pasted.

What was run

At 1762f74d396ab1dd07f668f6fac6d965f66ec66b, the four commands CONTRIBUTING.md
names and the runner's own check:

$ go build ./cmd/... ./internal/...
$ go vet ./cmd/... ./internal/...
$ gofmt -l cmd internal
$ go test -count=1 -v ./cmd/... ./internal/...
ok  	github.com/Flowfin/lab/cmd/contexts	0.565s
ok  	github.com/Flowfin/lab/cmd/lab	3.157s
ok  	github.com/Flowfin/lab/cmd/notices	11.070s
ok  	github.com/Flowfin/lab/cmd/pullrequest	1.023s
ok  	github.com/Flowfin/lab/internal/check	2.832s
ok  	github.com/Flowfin/lab/internal/contexts	1.651s
ok  	github.com/Flowfin/lab/internal/hardware	1.025s
ok  	github.com/Flowfin/lab/internal/invariants	2.641s
ok  	github.com/Flowfin/lab/internal/notices	1.216s
ok  	github.com/Flowfin/lab/internal/prose	2.222s
ok  	github.com/Flowfin/lab/internal/pullrequest	1.027s
$ go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
26 decision records read
the time this run read is 2026-08-26T21:28:04Z
0 refused

go build, go vet and gofmt -l printed nothing, which is the passing result
for all three. The -v run printed the harness disclosure, so this run covered
less than everything that exists and says which part:

the integration-hardware harness was not asked for and nothing in it ran.
    go test -tags integration_hardware ./internal/hardware
with LAB_INTEGRATION_HARDWARE=1 in the environment. its results are about that
machine and are not this suite's results.

The four states the new text pastes were each read before the text was written,
not afterwards:

$ gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
pull_request
$ gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
required_status_checks
pull_request
$ gh issue view 46 --repo Flowfin/lab --json state,closedAt --jq '"\(.state) \(.closedAt)"'
CLOSED 2026-08-24T19:11:13Z

The fourth state is the key-custody question, which I keep elsewhere rather
than on this board; I read it in the same pass and it was open.

What this does not do

It does not finish #55. The leg of that issue nothing in this tree can reach is
still open: allowed_merge_methods on this board is a ruleset parameter rather
than a file, and it still prints all three methods.

$ gh api repos/Flowfin/lab/rules/branches/main \
    --jq '.[] | select(.type=="pull_request") | .parameters.allowed_merge_methods'
["merge","squash","rebase"]

It does not add a signature requirement to either ruleset and does not argue for
one. It changes what a document says, and it changes no setting.

It touches only the one section. The rule-type table, the parameter table and
everything above ### The rule neither board carries are untouched, and I
re-read the two rule-type commands above rather than trusting those rows, but I
did not re-walk the nine parameter rows in this change and make no claim about
them here.

No second person has read this. The approving review count on this board is
zero, which the parity document records as a deliberate row, and there is no
reviewer tonight. The evidence above stands in place of one: every state the new
text asserts is pasted with the command that printed it, and the whole change is
five lines removed and forty-four added inside one section of one document.