Dependabot and the exact-pin gate will fight every cycle until the ecosystem config decides it

[CameronBrooks11]

Adding .github/dependabot.yml produced PR #32 within minutes, and it fails this repository's own gate. It will keep failing, identically, every cycle.

What happens

tests/test_packaging.py::test_every_action_in_the_release_workflow_is_pinned_to_an_exact_ref reads release.yml and rejects any bare floating major:

floating = re.findall(r"uses:\s*(\S+@v\d+)\s*$", RELEASE.read_text(), re.MULTILINE)
assert not floating, f"pin these to an exact version or SHA: {floating}"

main satisfies it with exact patch refs and one SHA:

actions/checkout@v4.2.2
astral-sh/setup-uv@v5.4.2
actions/upload-artifact@v4.6.2
actions/download-artifact@v4.3.0
pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2

Dependabot rewrites those to floating majors, and CI says so (run 34074267128, Test 3.12 and 3.13):

AssertionError: pin these to an exact version or SHA:
  ['actions/checkout@v7', 'astral-sh/setup-uv@v7', 'actions/checkout@v7']

The gate is doing its job. Its docstring says why: "The publish step holds this project's OIDC identity for PyPI, which is exactly the thing not to leave on a moving ref." Dependabot has no way to know that, and nothing in the repo tells it.

Why this is an issue and not just a PR comment

The diagnosis currently lives on PR #32. Dependabot supersedes its own PRs — the next cycle opens a new one and closes that, taking the reasoning with it. The next person sees a red bot PR with no history and re-derives it, or worse, merges past it.

Note also what the gate does not cover: it reads release.yml only. Dependabot's bumps to ci.yml and the other workflows are unaffected and are exactly the kind of update this repo wants applied automatically. So this is not "Dependabot versus the repo" — it is one file.

Options

1. Exclude the release workflow from the actions ecosystem. Dependabot has no per-file ignore for github-actions, so this means either a second ecosystem entry with a narrower directory, or ignore entries for the four actions release.yml uses — which would also stop them being updated in the workflows where floating is fine. Needs checking before it is chosen.
2. Let Dependabot open it and fix the pin by hand each cycle: take its version, write it as an exact patch ref. Cheap per occurrence, recurring forever, and depends on someone remembering why.
3. Pin everything by SHA with a version comment, as the publish step already does. Dependabot updates SHA pins and preserves the trailing comment, so its PRs would then satisfy the regex on their own. This is the option that makes the conflict disappear rather than managing it, and it strengthens the rest of the workflow to the standard the publish step already meets. My recommendation, but I have not verified Dependabot's SHA-updating behaviour on this repo — that check is the first step, not an assumption.

Done when

• release.yml and the Dependabot configuration cannot produce a red PR for this reason
• whichever option is taken is recorded where the gate is, so the next person meets the reasoning and not just the assertion
• a Dependabot actions PR merges green, proving the arrangement rather than describing it

Refs #32. Same family as partspec's ruff-pin conflict.