ci(release): use RELEASE_PAT so Publish workflow auto-fires

[telivity-otaip]

Summary

The Release workflow's gh release create call was authenticated with the default GITHUB_TOKEN. GitHub Actions intentionally does not trigger downstream workflows for events fired by GITHUB_TOKEN — that's why the Publish-to-npm workflow has never auto-fired off the release: published event for v0.7.0 or v0.7.1. Both releases sat on GitHub until someone manually clicked "Run workflow" on Publish.

This PR switches the create-release step to a Personal Access Token (RELEASE_PAT secret), which makes the event "user-fired" and propagates it to downstream workflows.

Behaviour

• RELEASE_PAT set → release creation propagates → Publish workflow auto-fires → packages reach npm with no manual intervention.
• RELEASE_PAT unset → falls back to GITHUB_TOKEN. Release still gets created (so the workflow doesn't break), but Publish stays manual. This keeps the workflow functional during the brief window between merging this PR and adding the secret.

One-time setup (repo admin)

1. Create a fine-grained PAT at https://github.com/settings/personal-access-tokens/new:
   • Repository access: telivity-otaip/otaip only.
   • Permissions → Repository permissions → set Contents: Read and write. That's the only scope needed for gh release create.
   • Expiration: pick a value you'll remember to rotate (90 days is reasonable).
2. Copy the token.
3. In the repo: Settings → Secrets and variables → Actions → New repository secret → name RELEASE_PAT, value the PAT.

After the secret is set, the next release PR you merge will auto-publish.

Why not GITHUB_TOKEN

Per the GitHub Actions docs:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.

Sensible default for most repos; problem for ours specifically because we want the release event to fan out.

Alternatives considered

• workflow_call chain — refactor Publish into a reusable workflow and have Release call it directly. Avoids the PAT but couples the two workflows; both would need to live in the same repo and the manual Publish trigger becomes more awkward. Rejected as more invasive than necessary.
• gh workflow run publish.yml as a final step in Release — works without a PAT, but loses the GitHub-native release-event trigger model and complicates retries.

The PAT approach is the standard fix and minimal-touch.

Test plan

• One-line wiring change with a fallback so unconfigured environments don't break.
• After merge: admin adds RELEASE_PAT secret.
• Next release PR (v0.7.2) merges → Release runs → Publish auto-fires → npm view @otaip/core version returns 0.7.2 without manual intervention.

🤖 Generated with Claude Code