ci(publish): add id-token: write to reusable workflow jobs

[martyy-code]

Summary

Adds id-token: write to the permissions block of the single job in each of the three reusable publish workflows. Required so npm Trusted Publishing can generate a Sigstore-signed provenance attestation.

Why

GitHub Actions does not propagate permissions from a calling workflow to a called reusable workflow. As the GitHub docs put it:

permissions can only be maintained or reduced — not elevated — throughout the chain.

The publish.yml entrypoint declares id-token: write on each caller job, but the OIDC token is minted in the context of the called workflow's job. The previous permission block on the reusable job (contents: read only) was insufficient — npm's OIDC exchange succeeded (Trusted Publisher validated) but npm refused to emit the provenance attestation because the OIDC context did not carry the id-token: write scope.

Observed on the dummy e2e test (PR #370):

EUSAGE Provenance generation in GitHub Actions requires
"write" access to the "id-token" permission

_publish-canary.yml reached the publish step, npm authenticated, then failed at provenance generation. Failures were marked on the whole workflow run, with release and hotfix skipped correctly (routing) but the canary step failed.

Changes

• _publish-release.yml: add id-token: write to the job's permissions.
• _publish-hotfix.yml: same.
• _publish-canary.yml: same (plus the existing pull-requests: write and contents: read).

3 insertions, 3 deletions. Each reusable workflow now declares its own OIDC dependency.

Senior rationale

The senior pattern is: every reusable workflow declares its own dependencies. The entrypoint's id-token: write stays as a documentation hint and as a defense-in-depth measure (the entrypoint job still requires the permission even though the reusable job's permission is what matters), but the reusable workflow must not assume the caller provided it.

Removing id-token: write from the entrypoint would not change the behavior, but keeping it makes the chain self-documenting: a reader of publish.yml can see at a glance that OIDC is required.

Test plan

• pnpm turbo type-check passes.
• pnpm turbo lint passes.
• Post-merge: re-run the dummy e2e test (PR docs(fp): dummy e2e release test (1.0.1 -> 1.0.2) #370 workflow run) → publish step succeeds, snapshot appears under @canary dist-tag with provenance.
• Subsequent: the Version Packages PR auto-generated by changeset-version.yml after merging docs(fp): dummy e2e release test (1.0.1 -> 1.0.2) #370 publishes @latest with provenance.

Risk

Very low. This is a permission addition (broadening). It cannot reduce functionality. The risk that was there (a publish path that fails with EUSAGE) is removed.

Rollback

Revert the merge commit. The original behavior (EUSAGE on provenance) returns.

🤖 Generated with Claude Code