Read the workflow list at the head that carries the new leg

[iderex]

The issue this belongs to

Refs #81. It does not close it: what that issue still holds is the analysis over
the core's own language, which waits on #11, and an upload to the code-scanning
surface.

What changed

docs/gate-parity.md pastes a reading of what this repository runs today, and it
is what a satisfied row points at. The row added under #81 names
.github/workflows/shell-analysis.yml, and that paste did not list it, so a row
and a reading inside one document disagreed.

The reading is re-run at the head that carries the leg and re-stamped with that
commit. The paragraph above it names this as the third row to move from naming a
plan to naming a run, and says why this half could not land in the same change as
the row.

What failure it prevents

The table is what a reader compares a run against. A row saying a check runs here
and a reading two paragraphs above it that does not list the file are worse
together than either would be alone: the reader cannot tell which of the two is
stale, so neither is usable, and the table's whole value is that a verdict can be
checked against a command.

Evidence

The reading and its stamp, before this change:

git grep -n 'b412218c1c1a8ed32e415c34f11f652ea8cf4864' origin/main -- docs/gate-parity.md
origin/main:docs/gate-parity.md:114:Read at `b412218c1c1a8ed32e415c34f11f652ea8cf4864` on this repository's default

What the same command answers now:

gh api repos/Flowfin/core/contents/.github/workflows --jq '.[].name'
dco.yml
dependency-review.yml
doc-paths.yml
pr-hygiene.yml
scorecard.yml
shell-analysis.yml
unicode-guard.yml
zizmor.yml

git rev-parse origin/main
7a8b187e8e1fb61ee769f57ba2d6bf8389ee2fb3

The document check passes on this branch:

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

What this does not cover

WHY THIS IS A SECOND PULL REQUEST ON ONE ISSUE, stated rather than left to be
noticed. The command in that paste reads the default branch through the API, so it
answers with the new file only after the merge that adds it. The file says as much
about the two rows that moved before this one, and both of those repairs came
after their merge for the same reason. Landing it inside the first change would
have meant pasting output the command did not produce.

NOT REFRESHED: the other pasted reading in that file, of the workflow files on the
gate this table is measured against. Nothing in this change touches that
repository, so its stamp still says what it said.

NOT COVERED: no mechanism. Nothing in this tree compares a pasted reading against
the thing it read, so the next row to land will drift in the same way and be
repaired by hand again.

Who has read it

Nobody but me. There is no second reader on this board tonight, and the commands
above and the checks on this pull request stand in place of one rather than the
question being left open.