Walk the rest of the ruleset, not only the required checks

[iderex]

The parity document walks the required status checks of the target gate and says
kept, renamed or dropped for each. A required set is only part of what stands
behind a merge. The rest of the ruleset decides who may push, what a merge does
to the commits it lands, and whether anybody has to read a change, and none of
that has been walked against the target.

Print both rather than trusting this body:

gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main --jq '.[].type'
gh api repos/Flowfin/lab/rules/branches/main \
  --jq '.[] | select(.type=="pull_request") | .parameters'

At the time of writing both boards refuse deletion, refuse a non-fast-forward
push and require a pull request, and the target adds the required status checks
that issue #26 lands here. What is left is the pull-request rule's own
parameters and the rules neither board carries.

The one deviation worth closing rather than reasoning away is the set of merge
methods. The target allows a merge commit only. This board allows a merge
commit, a squash and a rebase, and the last two rewrite the commits they land.
That is not a style preference here. The code-removal decision requires a record
to name the commit that removed the code, and that line is written in the same
change as the removal, so it names a commit that a squash replaces with a
different one. The record then points at nothing on the default branch while
still looking complete. The hand-over path has the same shape one step further
out, because a promotion section names a commit range in this repository.
Restrict the methods to what keeps a named commit resolvable, and write that
reason at the restriction rather than only here.

The parameters that stay as they are, each with its line of reasoning, because a
setting left at its default and a setting chosen deliberately look identical
afterwards. The approving review count is zero on both boards and stays zero
here, since a count above zero on a board where I am the only reviewer refuses
every merge, and a rule nobody can satisfy gets switched off in a hurry rather than
met. Stale-review dismissal, last-push approval and thread resolution are off on
both and stay off, because each of them only bites where a review is required
and none of them means anything at a count of zero. Bypass actors are empty on
both, and #26 already requires that they stay empty.

One rule neither board carries is a verified signature on every commit. This
issue does not add it and does not argue against it. Whether to require one is a
question about key custody rather than an engineering judgement, so it is an
entry on issue #46 and this document points there instead of deciding.

The walk belongs in docs/quality-parity.md as a second section rather than in a
file of its own, so a reader asking what stands behind a merge here finds the
whole answer in one place instead of the checks in one document and the ruleset
in another.

Done when docs/quality-parity.md carries a section listing every rule type the
commands above print for both boards, every parameter of the pull-request rule
with kept or changed and a reason for each change, the merge methods on this
board are restricted to the set that section names with the reason written at the
restriction, and the section names issue #46 for the one decision it does not
take.

[iderex]

The document half landed in #115, merged as 865715cf1566ecd93aae192d2fa7c5f776d553c7. docs/quality-parity.md now walks every rule type both rulesets print, the enforcement and bypass list that no rule-type command prints, and every parameter of the pull-request rule with the target's value beside it and a reason on each row. The section points at #46 for the signature entry rather than deciding it.

The third leg of the done-when is not in that change and cannot be. allowed_merge_methods is a parameter of the gate ruleset, not a file in this tree, so nothing a pull request here contains moves it:

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

The section states the reason the set has to be ["merge"], from record 0004 and record 0005, and states that all three are still allowed today rather than describing a restriction that is not there. This closes when that command prints ["merge"].

[iderex]

The parameter table in that section listed eight rows and the command above it
prints nine names, so the sentence opening the table was not true of the table.

gh api repos/Flowfin/lab/rules/branches/main \
  --jq '[.[] | select(.type=="pull_request") | .parameters | keys[]] | length'
9

require_extra_approval_for_unattributed_changes was the one outside it, printed
true on both boards, and never present anywhere in this tree:

git grep -n 'require_extra_approval_for_unattributed_changes' 819c7f0084f659a595bec4b1e8a2c11f0f3cdfe3^1
exit=1

Its absence mattered more than a missing row usually does. The four
review-adjacent rows each say they bite only where a review is required and none
is required at a count of zero, and this parameter is not in that family: it is
written to ask for an approval where a change carries commits the pull request's
author is not credited with. Left out, it read as agreeing with the four rows
that say nothing bites.

#156 adds the row and merged as
819c7f0084f659a595bec4b1e8a2c11f0f3cdfe3. The row says what the two commands
print and nothing about what the parameter does at a review count of zero, which
is a statement about the platform that no command in this walk answers.

The other eight parameter rows, the rule-type table and the enforcement and
bypass paste were all re-read at the same time and every value still holds.

Two sections of the same document are missing for a reason that has nothing to do
with this issue. d3edfc95b8526033c79cb26afe48282c2c090e32 removed the five
names with no verdict and the whole of ## Which contexts arrive, and on which pull requests, landed for #26 and #62, and the file went from 631 lines to 209.
That is #155, and the row added here sits below both, so putting them back is an
insertion.

Nothing here moves the leg the note of 2026-08-10 is about, and that note is not
restated.

[iderex]

What this waits on

The allowed_merge_methods edit on this board, from all three methods to the one that keeps a named commit resolvable.

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

That parameter lives on the ruleset rather than in this tree, so no change here reaches it. It is the last leg of the done-when: the section in docs/quality-parity.md is on the default branch, and I re-ran every command it pastes against both boards and the live API, with all nine parameter rows, the four rule types and the enforcement and bypass paste still returning what the document says they return.