ci: check the report action's tag against the workspace version

[maskjelly]

Closes #386.

What changed. The report@vX.Y.Z tag is pinned in three hand-maintained files, and the workspace version is a fourth copy of the same number. The action's own README was still at v0.10.1 — releases bumped two of the three and missed it twice. This PR:

1. Moves .github/actions/report/README.md to v0.11.1, so all three refs match workspace.package.version.
2. Names all three files in docs/RELEASING.md step 1, beside the flag gate.
3. Adds check-report-pin.sh — the "better still" from the issue — in CI's docs job beside check-candidate-statement.sh, and tools/report-pin-gate-selftest/run.sh in gates-listed beside the link gate's selftest, with CONTRIBUTING §1 listing both.

What the gate checks. Every actions/report@vX.Y.Z ref in the three files must equal workspace.package.version. It fails on a stale ref, on one stale ref among several, and on a listed file whose ref is gone entirely (a copy that quietly disappeared is drift too). The file list is a single default in the script, so the next file to carry the pin is a one-line addition. REPORT_PIN_VERSION exists only so the selftest can pin its fixtures to a version that does not move every release; CI never sets it, and the script header says so.

How it is proven. The selftest asserts the four failure shapes (matching passes; stale fails; absent fails; one stale among two fails) and — the assertion that keeps it honest — the repository's own three files against the real version. All five green locally, as are check-candidate-statement.sh, check-readme-links.sh and check-ci-gates-listed.sh.

Not done, deliberately. No CHANGELOG entry: no user-facing change, matching the link-gate precedent (#353). And the gate checks the three current files, not every report@ string in the repository — a repo-wide grep would flag the historical pins CHANGELOG entries quote, which are correct as history. If you would rather it scan wider with an exclusion list, that is an easy change.

One note on ordering. The CONTRIBUTING.md §1 lines this adds sit in the same block as the link-gate invocation line that #407 touches; whichever of the two lands second, I will rebase it.

[vyncint]

Thanks! Merging as is.

I hand-edited the pin in each of the three real sites in turn and the gate went red on every one, naming the file and both versions:

::error::.github/actions/report/README.md pins `report@v0.10.1` but the workspace version is 0.11.1

Two things you did that the issue did not ask for and that make this gate worth having.

The absent.md fixture — a listed file that has lost its pin — covers a failure the issue never named, and it is the one that would let a silent deletion through. A gate that only checks the pins it finds is a gate that passes when someone deletes the line.

Pinning REPORT_PIN_VERSION to 9.9.9 in the fixtures keeps them from going stale at every release, while the last assertion still runs the real three files against the real workspace version. That is the difference between a selftest and a second thing to maintain.

You were also right to exclude the report@v0.11.1 in CHANGELOG.md: it is historical prose under a released heading and must not move. Requiring the actions/ prefix is the right way to say that.

One thing for a later PR, not this one: check-ci-gates-listed.sh extracts only - run: cargo … lines, so its green says nothing about either of your two new steps. You listed both in CONTRIBUTING §1 by hand and correctly, but nothing enforces it — that is #383, already open.