Package Release never starts: caller declares no permissions block

[thedavidmeister]

Part of the org-wide repo refactor tracked in rainlanguage/rainix#296, though this is an independent CI defect rather than split work.

Problem

This repo's Package Release workflow has never run. Its last three runs all ended in startup_failure — GitHub rejects them before creating a single job, so there are no logs, no jobs and no annotations to inspect.

Cause

rainix-autopublish.yaml's release job declares:

permissions:
  id-token: write
  contents: write

A called workflow can only narrow the token it is handed, never widen it. This repo's package-release.yaml declares no permissions: block, so the job gets the repo default — and this repo is set to default_workflow_permissions: read. Requesting write against a read allowance is an upgrade, so the run is rejected:

The nested job 'release' is requesting 'contents: write, id-token: write',
but is only allowed 'contents: read, id-token: none'.

The correlation across all 30 org repos calling rainix-autopublish is exception-free: 3 of 3 repos with read fail at startup, 27 of 27 with write start normally.

Fix

Grant it explicitly on the calling job, rather than flipping the repo Actions setting:

jobs:
  release:
    permissions:
      contents: write
      id-token: write
    uses: rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@main
    ...

Fixing it at the caller keeps the requirement visible in the repo rather than depending on an invisible org/repo setting. The same fix is open on the other two affected repos: rainlanguage/rain.flare#206 and rainlanguage/rain.tofu.erc20-decimals#28.

Verification limit

Package Release triggers only on push to main, so no PR branch can exercise it end to end. Proof is the first post-merge push to main producing a run that creates its release job.