Grant contents:read to publish workflows for internal repo checkout

quicknode/cli is `internal` visibility, which GitHub Actions treats as
private for auth purposes. Reusable workflows mint their own
GITHUB_TOKEN scoped to the called workflow's declared permissions (NOT
inherited from the caller's secrets: inherit). When a reusable workflow
omits a permissions block, the auto-minted token has zero permissions
on the repo's contents, and actions/checkout gets a 404 ("Repository
not found") on the clone fetch.

Fix in two coordinated edits:

* publish-crates.yml and publish-docker.yml now declare
  `permissions: contents: read` at the workflow level.
* dist-workspace.toml gets a github-custom-job-permissions block so
  the calling jobs (custom-publish-crates, custom-publish-docker) also
  grant contents: read. Reusable workflow permissions cannot exceed
  the caller's, so we had to widen both sides.

This is invisible on public repos because anonymous git fetches against
github.com Just Work. We only hit it because the repo is internal.

The previous run produced a valid GitHub Release at v0.1.0 (all
artifacts and attestations uploaded successfully — only the two
publish jobs failed). To pick up this fix we'll delete that release +
tag and re-tag; nothing has actually been published to crates.io or
GHCR yet, so the teardown is purely a git/Releases-page cleanup.

Author: johnpmitsch

.github/workflows/publish-crates.yml

@@ -12,6 +12,14 @@ on:
         required: true
         type: string
 
+# Reusable workflows mint their own GITHUB_TOKEN with only the permissions
+# declared here (NOT inherited from the caller). On a private/internal
+# repo, actions/checkout needs `contents: read` or it gets a 404. The
+# caller must also grant this — see dist-workspace.toml's
+# github-custom-job-permissions block.
+permissions:
+  contents: read
+
 jobs:
   publish:
     runs-on: ubuntu-22.04

.github/workflows/publish-docker.yml

@@ -18,10 +18,13 @@ on:
 
 # Permissions must NOT exceed what the caller (release.yml's
 # `custom-publish-docker` job) grants — reusable workflows can't widen
-# permissions. cargo-dist gives custom publish jobs id-token + packages
-# write, plus the workflow-level contents: write inherited via the
-# caller. That's enough for GHCR push and gh release download.
+# permissions. Caller grants are configured via dist-workspace.toml's
+# github-custom-job-permissions block. `contents: read` is needed for
+# actions/checkout on this internal repo; `packages: write` is needed
+# for GHCR push; `id-token: write` is needed for OIDC-backed
+# attestations on the pushed image.
 permissions:
+  contents: read
   packages: write
   id-token: write
 

.github/workflows/release.yml

@@ -297,8 +297,7 @@ jobs:
     secrets: inherit
     # publish jobs get escalated permissions
     permissions:
-      "id-token": "write"
-      "packages": "write"
+      "contents": "read"
 
   custom-publish-docker:
     needs:
@@ -311,6 +310,7 @@ jobs:
     secrets: inherit
     # publish jobs get escalated permissions
     permissions:
+      "contents": "read"
       "id-token": "write"
       "packages": "write"
 

dist-workspace.toml

@@ -31,3 +31,12 @@ formula = "qn"
 publish-jobs = ["./publish-crates", "./publish-docker"]
 # Emit SLSA build attestations for every binary archive. Critical for a credential-handling tool.
 github-attestations = true
+
+# The repo is `internal`, so the reusable workflow's auto-minted
+# GITHUB_TOKEN needs explicit contents:read to checkout the source.
+# Without this the actions/checkout step in each publish workflow
+# fails with `Repository not found` (a 404 masquerading as a missing
+# auth claim on a private repo). Granting the permission here widens
+# the calling job's permission grant so the called workflow can also
+# declare contents:read without exceeding the caller.
+github-custom-job-permissions = { "publish-crates" = { contents = "read" }, "publish-docker" = { contents = "read", packages = "write", "id-token" = "write" } }