gh release create --target $RELEASE_COMMIT 403s under GITHUB_TOKEN when the commit isn't branch-reachable

cargo-dist's `host` job runs:

gh release create "$TAG" --target "$RELEASE_COMMIT" --title ...

against the runner's default `GITHUB_TOKEN`. When `$RELEASE_COMMIT` happens to be a SHA that isn't on any branch in the repo (e.g. when a tag was force-pushed to a new commit without also updating the branch it was cut from), the GitHub API returns:

HTTP 403: Resource not accessible by integration

even though the token's setup log shows `Contents: write`. This is a documented, long-standing scope restriction on the Actions integration token — see [cli/cli#9514](https://github.com/cli/cli/issues/9514). PATs are unaffected.

For normal release flows where tags are cut from the tip of a release branch this never bites, but it's a sharp edge for anyone iterating on releases in a fork (force-pushing tags during testing) and produces a confusing 403 that looks like a permissions misconfiguration.

Possible fixes:

- Omit `--target` and let GitHub default to the tag's commit (simplest if cargo-dist doesn't need to override).
- Pass `--target ` instead of a SHA when a branch reachable from the tagged commit is known.
- Document the gotcha in the troubleshooting section.

Hit while testing cargo-dist on a fork of [cedar-policy/cedar](https://github.com/cedar-policy/cedar). Happy to send a PR for whichever direction you'd prefer.

Start with cargo-dist's generated host job and its `gh release create` command, then review the linked cli/cli#9514 behavior for the token restriction. Reproduce the failure with a tag target that is not branch-reachable and determine which proposed direction the project prefers. Done means the release flow avoids the confusing 403 or clearly documents the limitation in troubleshooting guidance.

Written by the indexing model from the issue text.