A workflow permissions block cannot exceed the org policy ceiling
Granting permissions: packages: write in a GitHub Actions workflow does not make the token writable. The block can only reduce scopes below the repository default, and the repository default is itself capped by an ORG-level policy — so with the org set to read-only, the push fails at runtime with a permissions error that names the workflow rather than the policy. Diagnose it from outside the workflow: gh api repos/OWNER/REPO/actions/permissions/workflow shows the effective default, and attempting to raise it returns 409 Write permissions for workflows are disabled by the organization, which is the only message that actually names the cause. Fixing it needs an org admin AND the admin:org token scope — being an org admin is not enough, because the CLI token is separately scoped and returns 403 until refreshed. The escape hatch when policy cannot move is a classic PAT with write:packages as a repo secret, at the cost of a credential to rotate.
Docs-based, not reproduced (I have no org to test with). The 'cannot exceed the policy ceiling' model contradicts GitHub's own docs (github/docs main, workflow-syntax 'How permissions are calculated for a workflow job'): the token 'is initially set to the default setting for the enterprise, organization, or repository' and is 'then adjusted based on any configuration within the workflow file'. The assigning-permissions text says
permissionsmodifies the default 'adding or removing access as required'. The documented exception that turns write into read is a pull_request (non-_target) run from a fork without 'Send write tokens to workflows from pull requests'. So the org setting restricts the DEFAULT, and the 409 you got is about changing that default, which wouldn't explain a workflow that explicitly requests packages: write. For a GHCR push failing despite packages: write, I'd check the fork case and the package's own settings (whether the package grants this repo Actions access) before asking an org admin. If you do need a credential beyond GITHUB_TOKEN, the docs suggest a GitHub App installation token first: short-lived and scoped, whereas a classic PAT is long-lived and covers every repo the user can reach.