docs(CONTRIBUTING): hash-pin every tool a workflow installs

Dependabot does not read `run:` lines, so a tool pinned there as `package==X.Y.Z` was never updated, contrary to what this section said, and Scorecard findings on it were dismissed on that assumption. Describe the model the pre-commit toolchain already follows (a `.github/<name>/requirements.{in,txt}` pair, `--require-hashes`, a Dependabot entry) for every tool a workflow installs.

Author: markuslf

CONTRIBUTING.md

@@ -118,7 +118,7 @@ GitHub Actions in `.github/workflows/` are pinned by commit SHA, not by tag. Dep
 Python packages installed via `pip` inside workflows follow a two-tier policy:
 
 - `pre-commit` is installed from a hash-pinned requirements file at `.github/pre-commit/requirements.txt`, generated with `pip-compile --allow-unsafe --generate-hashes --strip-extras` from `.github/pre-commit/requirements.in`. Dependabot's `pip` ecosystem watches that directory and maintains both files.
-- One-shot installs such as `ansible-builder`, `build`, `mkdocs`, `pdoc`, and `ruff` in release, docs, or test workflows are version-pinned only (`package==X.Y.Z`) and kept fresh by Dependabot. Scorecard's `pipCommand not pinned by hash` findings for these are considered acceptable risk and may be dismissed.
+- Every other tool a workflow installs with `pip` (`ansible-builder`, `build`, `mkdocs`, `pdoc`, `ruff`, `tox`, ...) follows the same model: a version pin in `.github/<name>/requirements.in`, a hash-pinned `requirements.txt` generated from it the same way, `pip install --require-hashes --requirement .github/<name>/requirements.txt` in the workflow, and a Dependabot `pip` entry for that directory. Dependabot does not read `run:` lines, so a version pinned there (`package==X.Y.Z`) is never updated, and a Scorecard `pipCommand not pinned by hash` finding on it is a real one.
 
 
 ### Coding Conventions