Release v0.1.3 (#8)

Release v0.1.2 (#6)

Release v0.1.1 (#4)

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.