The permissions key on a workflow or job does not merge with the default token scopes. Specifying it switches the token to a deny-by-default model where every scope not listed becomes none.
This is the intended design and is why permissions: contents: read is the recommended baseline, but it breaks workflows incrementally. A job that adds permissions: packages: write to publish an image loses contents: read and the checkout step then fails on a private repository with a 403. The error names the repository, not the permissions block, so the cause is easy to miss.
List every scope the job needs. To grant everything the token can have, use permissions: write-all, and to drop everything use permissions: {}. Repository and organization settings also cap what the token can be granted: if the default workflow permission is set to read-only, a job requesting contents: write gets read, silently. Check the actual grant in the run log, which prints the resolved permission set at the top of each job under the token section.