INFR: Harden workflow permissions, action pinning, and PyPI publishing

[mmcky]

Problem

Standard supply-chain protections are absent from the CI/publishing pipeline (no known incident — this is hygiene). Repository-level settings (default GITHUB_TOKEN scope, Actions PR-approval, branch protection on main) are being hardened directly by the maintainers; this issue tracks the workflow-file and publishing changes that need code:

1. No permissions: blocks in either workflow, so every job — and every third-party action it invokes — runs with the repository-default token scope rather than least privilege.
2. Third-party actions are pinned to mutable major tags (conda-incubator/setup-miniconda@v4, coverallsapp/github-action@v2), which resolve to whatever the tag points at today and offer no integrity guarantee.
3. PyPI publishing uses a long-lived PYPI_TOKEN secret in the publish job. PyPI Trusted Publishing (OIDC) has been the recommended mechanism since 2023 — short-lived, workflow-bound credentials with nothing to leak at rest. The job also has no environment: gate, so there is no approval step between a tag push and a public release.
4. Dependabot monitors github-actions only, so Python dependencies get no automated freshness or vulnerability signal.

Proposed change

1. Add a top-level permissions: contents: read to both workflows; grant job-level extras only where needed (id-token: write on the publish job).
2. Pin third-party actions to full commit SHAs with the version in a trailing comment (Dependabot updates SHA-pinned actions, rewriting SHA and comment together).
3. Register the repo/workflow as a Trusted Publisher on PyPI; switch the publish step to OIDC; gate it behind a protected environment: (e.g. pypi); revoke and delete PYPI_TOKEN once the first OIDC publish succeeds (verify on TestPyPI first).
4. Add the pip ecosystem to .github/dependabot.yml.

Acceptance criteria

• permissions: explicit in every workflow; publish job uses OIDC in a protected environment; no PyPI secret remains
• All third-party actions pinned to commit SHAs
• A tagged release publishes successfully via the new path
• Dependabot opens pip update PRs

---

From the July 2026 technical-debt audit (AI-assisted; claims verified against 28d4b3b and the GitHub API on 2026-07-25).

[mmcky]

Status update: the repository-settings half of this hardening is done (applied 2026-07-25, verified via the API):

• Default workflow GITHUB_TOKEN permissions set to read; "Allow GitHub Actions to create and approve pull requests" disabled.
• Branch protection enabled on main: pull request required before merging, force-pushes and deletions blocked, rule applies to administrators.
• Required approvals: 0 — a deliberate choice for the current two-maintainer workflow: every change still goes through a PR with green CI, but solo maintenance isn't blocked when the other maintainer is away. Can be raised to 1 later if the workflow suits.
• Required status checks (from the ci.yml matrix): tests (ubuntu-latest, 3.12), tests (ubuntu-latest, 3.13), tests (ubuntu-latest, 3.14), tests (windows-latest, 3.14), tests (macos-latest, 3.14).

One maintenance coupling to be aware of: the required-check list matches names exactly, so when the Python matrix changes (or #873 alters workflows) the list must be updated by hand or merges will hang on a check that never reports. A nice hardening for whoever picks up the workflow-file half of this issue: add a small all-checks summary job (needs: [tests], fails if any leg failed) to ci.yml and require only that single stable name — then the protection rule never goes stale.

Remaining scope for this issue is the workflow-file work: permissions: blocks in both workflows, SHA-pinning conda-incubator/setup-miniconda and coverallsapp/github-action, Trusted Publishing (OIDC) behind a protected environment: with PYPI_TOKEN revoked after the first verified publish, and the pip ecosystem in Dependabot.