Give the gitleaks job the token it needs on pull requests

.github/workflows/ci.yml

@@ -119,5 +119,13 @@ jobs:
       - name: gitleaks over full history
         uses: gitleaks/gitleaks-action@ff98106e4c7b2bc287b24eaf42907196329070c7 # v2.3.9
         env:
+          # The action refuses to scan a pull_request event without this and
+          # exits before reading anything: "GITHUB_TOKEN is now required to
+          # scan pull requests". It passed on push, where it is not needed,
+          # so the job was green on main and red on every pull request. It is
+          # a required check, so that combination blocked all three pull
+          # requests this repository has had, including the one that would
+          # have upgraded this action.
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           GITLEAKS_ENABLE_UPLOAD_ARTIFACT: "false"
           GITLEAKS_ENABLE_SUMMARY: "false"

CONTRIBUTING.md

@@ -91,6 +91,31 @@ up last. A new evidence word — `Tested:`, `Confirmed:` — needs adding to the
 allowlist in both files before it can land there. That is the accepted cost of a
 tight list.
 
+### What the allowlist does not catch, on purpose
+
+Two things pass this gate that an earlier version of it would have stopped. Both
+are the deliberate reduction, not an oversight.
+
+**A vendor or tool name in the body of a message.** The allowlist reads the
+trailer block and nothing else, so such a name written in a paragraph of prose is
+ordinary text and is accepted. Attribution is stamped as a trailer, and an
+unlisted key is refused whether or not the gate has heard of the tool that wrote
+it — a stronger guarantee than a name list can give, because it does not need
+updating when a new tool ships. Matching words in prose is a different job, and
+the denylist that did it matched nothing across the full history of every
+repository in this family.
+
+**Anything in the working tree.** Nothing greps the checkout for vendor names.
+Hand-written hooks under `.git/hooks/` once did, and `core.hooksPath` makes git
+ignore that directory entirely, so any that survive there are inert. They have
+not been restored and should not be: it is the same scan with the same zero
+matches, and it walked build artefacts, so a full validation run could leave a
+clean tree unpushable.
+
+The same trade is taken in every repository that shares this gate. Consistency
+across them is the property worth keeping — a one-repository exception would be
+the defect, not the fix.
+
 **History was not rewritten when this changed.** No force push, no retag, nothing
 dropped; only the rule applied to new pushes is different.