Walk the signature rule both rulesets now carry

[iderex]

Refs #55

THIS IS SUPERSEDED BY #214 AND IS CLOSED UNMERGED

I opened this with no Signed-off-by trailer on its commit, and the DCO gate
refused it by name:

FAIL  8e0c5b80d34e62eb606e978cacf836e9fa450087 is missing: Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>

Every other check on this head passed. The repair is a new branch rather than a
rewritten one, because a history that has been pushed is corrected under a new
name and never overwritten. #214 carries the same change cherry-picked with the
trailer added, and the two trees are identical:

$ git diff 8e0c5b80d34e62eb606e978cacf836e9fa450087 83797fbea9242157a4271abb1e7399caeb703389 --stat
(no output)

This branch is left in place rather than deleted, because it was never merged.
The description of the change below is kept as it was written, so a reader
comparing the two pull requests sees the same body under both.

---

This does not finish #55. The last leg of that issue's done-when is an
allowed_merge_methods edit on the ruleset, which is not a file in this tree,
and nothing here reaches it.

What this changes

docs/quality-parity.md, in the ruleset walk that issue built, at three sites
and for two different drifts. No path is removed and no other file is touched.

The rule types moved and the walk did not. The subsection ### The rule neither board carries said a verified signature on every commit was required by
neither this board nor the target, over a paste read on 2026-08-26. Both require
one now. The heading is replaced, the paste is re-read, the rule-type table gains
a required_signatures row, the preamble that said three types here and four at
the target carries the newer reading beside it, and the sentence about what an
empty bypass list buys now counts four rules here rather than three.

The setting arrived ahead of the condition it was decided on.
docs/decisions/0023-signed-commits-on-the-default-branch.md makes the
requirement effective as the keys for the working accounts land, which an
issue I keep elsewhere sets up, and not before, and that issue is open. The subsection says so
with the command behind each half, so a configured rule is not read as the
decision having taken effect, and it keeps the other direction as well: nothing
in this tree reads a signature, so a green run still says nothing about one.

A second paste in the same subsection had drifted for an unrelated reason.
It quoted the closing moment of issue #46 as 2026-08-24T19:11:13Z, which was
correct when it was written. The issue was reopened on 2026-08-27T07:19:18Z and
closed again at 08:46:01Z. The value is repaired and the timeline it comes from
is now quoted beside it, because a closing timestamp moves whenever an issue is
reopened and the timeline is the authority a single value is not.

One edited line sits outside the walk. ## The gap this rests on pastes the
same rule-type command and carried the same three-element answer, so it is
repaired to the four the command prints. That section's surrounding prose is
about the required set, which is issue #26's subject; nothing in it changed
except the one line inside the fence, and the sentence it supports, that this
board requires no status check at all, is still what the command returns.

What failure it prevents

A reader quoting a row of this walk back as the state of a live setting when the
setting has moved. The walk already names that as the failure a document
describing a live setting always has, and the version this replaces was an
instance of it: a heading reading as a settled absence over a rule that is now
configured on both boards.

It also prevents the narrower reading that costs more. A rule that is configured
before the condition its record makes it effective on has been met is a merge
that refuses an unsigned commit while nobody is guaranteed to hold a key, and
that refusal lands at the end of somebody's work rather than at the start.
Leaving the document silent about it would let the configuration be read as the
decision having taken effect.

What was run

The four commands CONTRIBUTING.md names, at the commit being pushed, plus the
runner against this tree.

$ go build ./cmd/... ./internal/...
$ go vet ./cmd/... ./internal/...
$ gofmt -l cmd internal
$ go test -count=1 ./cmd/... ./internal/...
ok      github.com/Flowfin/lab/cmd/bom  5.655s
ok      github.com/Flowfin/lab/cmd/contexts     0.538s
ok      github.com/Flowfin/lab/cmd/lab  2.049s
ok      github.com/Flowfin/lab/cmd/notices      8.344s
ok      github.com/Flowfin/lab/cmd/pullrequest  0.578s
ok      github.com/Flowfin/lab/internal/bom     0.582s
ok      github.com/Flowfin/lab/internal/check   1.070s
ok      github.com/Flowfin/lab/internal/contexts        0.560s
ok      github.com/Flowfin/lab/internal/hardware        0.609s
ok      github.com/Flowfin/lab/internal/invariants      1.114s
ok      github.com/Flowfin/lab/internal/notices  0.561s
ok      github.com/Flowfin/lab/internal/prose   0.619s
ok      github.com/Flowfin/lab/internal/pullrequest     0.611s

$ 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-28T14:44:03Z
0 refused

gofmt -l printed nothing, which is its passing result. The suite was run
without -v here, so the line the hardware harness prints about not being asked
for is not in the paste above; nothing in this change touches that package.

Every paste the change adds to the document was read before the sentence resting
on it was written, and each one is reproduced here:

$ gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
pull_request
required_signatures
$ gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
required_status_checks
pull_request
required_signatures
$ gh issue view 46 --repo Flowfin/lab --json state,closedAt --jq '"\(.state) \(.closedAt)"'
CLOSED 2026-08-27T08:46:01Z
$ gh api repos/Flowfin/lab/issues/46/timeline --paginate \
    --jq '.[] | select(.event=="closed" or .event=="reopened") | "\(.event) \(.created_at)"'
closed 2026-08-24T19:11:13Z
reopened 2026-08-27T07:19:18Z
closed 2026-08-27T08:46:01Z
$ for c in 45bfe62 2edacce 43b4fae; do
    gh api repos/Flowfin/lab/commits/$c --jq '.commit.verification | "\(.verified) \(.reason)"'
  done
true valid
true valid
true valid

The key-custody state those pastes sit beside is a question I keep elsewhere
rather than on this board; I read it in the same pass and it was open.

The nine parameter rows of the pull-request rule were re-walked in the same pass
and every one still returns on both boards the value its row gives it, so no row
of that table is touched here:

$ gh api repos/Flowfin/lab/rules/branches/main \
    --jq '.[] | select(.type=="pull_request") | .parameters'
{"allowed_merge_methods":["merge","squash","rebase"],"dismiss_stale_reviews_on_push":false,"dismissal_restriction":{"allowed_actors":[],"enabled":false},"require_code_owner_review":false,"require_extra_approval_for_unattributed_changes":true,"require_last_push_approval":false,"required_approving_review_count":0,"required_review_thread_resolution":false,"required_reviewers":[]}
$ gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main \
    --jq '.[] | select(.type=="pull_request") | .parameters'
{"allowed_merge_methods":["merge"],"dismiss_stale_reviews_on_push":false,"dismissal_restriction":{"allowed_actors":[],"enabled":false},"require_code_owner_review":false,"require_extra_approval_for_unattributed_changes":true,"require_last_push_approval":false,"required_approving_review_count":0,"required_review_thread_resolution":false,"required_reviewers":[]}

What this does not do

It does not finish #55. allowed_merge_methods prints all three methods on this
board in the paste above, the table already marks that row as a change owed, and
the parameter lives on the ruleset rather than in this tree.

It does not decide whether required_signatures should stand on this board
before that key-custody issue closes. It records that it does, with the record's own
ordering beside it, and takes no position.

It proves nothing about accounts other than the one whose commits it read. Three
verified commits are three commits, not a property of every account that may push
here, and the document says so rather than reading them as a guarantee.

It repairs the two drifted pastes it found and does not re-walk the whole
document. The rule types and the nine pull-request parameters were re-read; the
required-set table, the contexts sections and the two sections
d3edfc95b8526033c79cb26afe48282c2c090e32 removed are untouched and unclaimed
here.

It was not read by a second person. There is no second reader on this board
tonight, so the commands above stand in place of one rather than a review having
happened, and this sentence is the disclosure rather than a softening of it.