Set persist-credentials: false on actions/checkout

[anish-sujanani]

Set persist-credentials: false on actions/checkout

actions/checkout writes a credential for the GITHUB_TOKEN into .git/config and leaves it
there for the rest of the job. Nothing in this repository is leaking it today — this change removes
the material that a later mistake would expose: an artifact upload whose path includes the
repository root, a debug step that prints git config, a broad Docker build context, or a
dependency's install script reading the workspace.

What changed

7 actions/checkout steps across 2 workflow files. One or two
added lines per step; nothing else moves.

• plugin-checks.yml → json-validation
• plugin-checks.yml → frontmatter-validation
• plugin-checks.yml → markdown-lint
• plugin-checks.yml → link-check
• plugin-checks.yml → structure-integrity
• plugin-checks.yml → version-sync
• release.yml → release

Why this is safe here

Six of the seven jobs are validation only (json-validation, frontmatter-validation, markdown-lint, link-check, structure-integrity, version-sync) and perform no git operation.

The seventh, release, is worth calling out because its name suggests otherwise: it runs gh release create with GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} set in env:. gh reads the token from the environment, never from .git/config, and the job does not run git push or git tag. So it is safe, and it is included.

A job only depends on the persisted credential if it runs git push or git tag against the
origin. Where a token is passed explicitly — via env: or as an action input — it is unaffected by
this change, because gh and actions read it from the environment rather than from git's config.

Verification

The edit was checked three ways before raising: the parsed YAML is identical once the added keys
are stripped, the number of added lines matches the number of actions/checkout steps in each
file, and actionlint reports no new issues.

If this breaks something

Say so and I will revert it — a defence-in-depth change is not worth a broken pipeline. If a job
turns out to need the credential, the fix is to authenticate explicitly rather than ambiently
(git push "https://x-access-token:$GH_TOKEN@github.com/$GITHUB_REPOSITORY.git" ...) and I am
happy to make that change instead.

Raised as part of a CI/CD security posture review (control PM_GH_REPO_036).