fix(release): scope id-token:write to the one job that publishes

[fas89]

The defect

release.yml grants three permissions at workflow level. Under Actions' inheritance
rules, a job with no permissions: block of its own gets the whole grant — and
three of the four jobs had no block:

job	before	can mint an OIDC token?
quality-gate	inherited contents:write id-token:write attestations:write	yes
build	inherited all three	yes
publish-pypi	own: id-token: write	yes — legitimately
github-release	inherited all three	yes

The report named two jobs; it is three. github-release was inheriting id-token: write too.

Why it matters here specifically

An OIDC token minted anywhere in this workflow may be accepted by PyPI as proof of
identity for data-product-forge-sdk. So any step in quality-gate or build — a
compromised third-party action reached through a floating tag, say — could request one
and publish, never entering the job that is supposed to be the only publisher.

The environment: pypi claim on publish-pypi blocks this only if the
trusted-publisher config on PyPI also pins that environment name. If that field is
blank, nothing distinguishes a token minted in build from the real one. That setting
is on pypi.org and can't be read from here, so this change does not depend on it.

⚠️ Worth checking either way: pypi.org → data-product-forge-sdk → Publishing →
confirm the "Environment name" field reads pypi and is not blank.

Precedent, not hypothesis: the March 2026 compromise of aquasecurity/trivy-action
rewrote 75 of its 76 tags and reached a backdoored LiteLLM release through that action
sitting inside LiteLLM's own CI.

After

workflow default   contents: read      <- was contents+id-token+attestations
quality-gate       contents: read
build              contents: read
publish-pypi       id-token: write     <- unchanged, the only minter
github-release     contents: write

attestations: write is dropped outright — it occurred exactly once in the file,
in the grant itself. Nothing ever used it.

The default drops to read-only, so a job added later without its own block gets the
safe end of the mistake.

Why tightening build is safe on evidence, not belief

release.yml is never exercised by PR CI, so this needed proof rather than reasoning.
Artifact upload/download use the Actions runtime token, not GITHUB_TOKEN —
demonstrated in this repo: publish-pypi already declares only id-token: write
(leaving it contents: none) and its download-artifact step succeeded in all three
successful releases (2026-05-12, 2026-06-01, 2026-06-27).

Verification

Effective per-job permissions computed the way Actions resolves them, run against
both revisions so the pass is evidence rather than silence:

BEFORE (upstream/main)   over-privileged jobs: ['quality-gate', 'build', 'github-release']
AFTER  (this branch)     over-privileged jobs: NONE

actionlint clean. One file changed.

Not in this PR

SHA-pinning every uses: is the same root cause and a real gap, but it's a larger
change with a genuine trade-off on pypa/gh-action-pypi-publish@release/v1 — PyPA
publishes that branch ref deliberately so security fixes land without action. Raised
separately rather than bundled here.

🤖 Generated with Claude Code