Anchor the parity clone to the commit the table is written against

[iderex]

The issue this belongs to

Closes #390

What changed

docs/gate-parity.md tells a reader how to get the repository the parity table
is measured against. That instruction cloned --depth 1 and pasted the head it
landed on as the commit the table is written against. It now clones without a
checkout and checks the commit out by name, so the sha is an argument rather
than an output.

Two paragraphs are added under the block saying what the old pair did, what it
cost, and why neither of this file's two existing repair shapes was taken.

What failure it prevents

A reader following the section in order reading one commit's workflow files
against a table written against another, with nothing in front of them saying
which is wrong. It has already happened rather than could: --depth 1 takes the
default branch head of a repository this board does not control, that head moved,
and no event here records it.

The old pair, run today:

git clone --depth 1 https://github.com/Flowfin/jellyfin-plugin-sso /tmp/old
git -C /tmp/old rev-parse HEAD
fadecd85c7764519977027eed209c87e88262419

against the 54c5bf468a4f8719309fd59aa7f448ab17bfbbf8 the file pastes under it.
The block below that pair is run inside the clone, and the file says of it that
it is the set which decides parity because it does not move between two readings
of one commit. From the clone the old pair makes, two of its twenty-four rows
come back changed - e2e-login.yml carries workflow_call where the paste has
release, and wiki-lint.yml has gained gollum.

Evidence

Run at fd53a614d6041fae4a1c7e43b9281d41a7d2e2c4, the commit being pushed.

The commands as this change writes them land on the commit the table names:

git clone --no-checkout --filter=blob:none https://github.com/Flowfin/jellyfin-plugin-sso ssoclone
git -C ssoclone checkout 54c5bf468a4f8719309fd59aa7f448ab17bfbbf8
git -C ssoclone rev-parse HEAD
54c5bf468a4f8719309fd59aa7f448ab17bfbbf8

and the block under them, taken out of the file at the pushed commit and run in
that clone, reproduces the pasted rows byte for byte:

git show fd53a614:docs/gate-parity.md | sed -n '76p' | sed 's/^    //' > awkblock.sh
cd ssoclone && bash awkblock.sh > out.txt
diff <(git show fd53a614:docs/gate-parity.md | sed -n '77,100p' | sed 's/^    //') out.txt
exit=0

The change is one file and one commit:

git diff --name-only origin/main...HEAD
docs/gate-parity.md
git rev-list --count origin/main..HEAD
1

Two gate legs that read this file were run here. doc-paths:

bash .github/doc-paths/doc-paths.sh check | tail -1
Every path these documents name resolves against the tracked set.

and the scan unicode-guard runs, where 1 is the clean answer:

rc=0; git grep -nIP '(*UTF)[\x{202A}-\x{202E}\x{2066}-\x{2069}\x{200E}\x{200F}\x{061C}\x{200B}-\x{200D}\x{2060}]' -- . || rc=$?; echo "rc=$rc"
rc=1

What this does not cover

The block that lists the other repository's workflow files is unchanged, and so
is every other reading in this file. Whether those still reproduce is not
re-asserted here; the readings taken under gh in this file were read elsewhere
today and this change touches none of them.

The line numbers in this file move by eighteen, so 76, 77 and 100 above are
where the block sits at the pushed commit and not where it sat on main. Any
reading taken against main and quoted afterwards would name the older numbers.

Nothing here refuses a future --depth 1 paste. No check in this tree re-runs a
command a document writes down, which docs/decisions/0269 states of itself, so
this repair is carried by the file and by whoever reads it.

The remaining legs of the gate were not run on this machine. coverage, build,
targets, cross-toolchain, test, lint, format and the rest are the
runner's, and this change touches no Rust and no workflow file.

Who has read it

Nobody other than me. There was no second reader available for this change, and
the evidence above stands in place of one.