ci: use PAT for release-please to trigger required CI checks

[mlorentedev]

Summary

PRs opened by the default GITHUB_TOKEN do not trigger pull_request workflows — GitHub suppresses these events to prevent infinite recursion when one workflow creates a PR that would trigger another. With branch protection on master requiring test / lint / security status checks, the auto-generated release-please PR ends up in BLOCKED state with no CI ever running.

This is what hit us today on PR #19 (v1.5.1). The previous release PR #15 (v1.5.0) silently dodged the issue because something retriggered CI manually 11 minutes after the PR opened (likely a UI "Update branch" click).

Fix

Pass an explicit PAT to release-please-action via the token: input. PRs created with a PAT appear as user-driven events to GitHub, so the pull_request trigger fires normally.

token: ${{ secrets.RELEASE_PLEASE_PAT || secrets.GITHUB_TOKEN }}

The || fallback to GITHUB_TOKEN means this PR is safe to merge before the secret is configured — the workflow keeps using the legacy behavior until the PAT is added. No disruption.

Setup checklist (one-time, after merging this PR)

• Generate a fine-grained PAT:
  • Repository access: Only select mlorentedev/ts-bridge
  • Permissions:
    • Contents: Read and write
    • Pull requests: Read and write
    • Workflows: Read and write (only if a release PR ever changes a .github/workflows/* file — uncommon)
  • Expiration: 1 year recommended, with calendar reminder
• Add it as repo secret RELEASE_PLEASE_PAT (Settings → Secrets and variables → Actions → New repository secret)
• On the next release PR, verify CI fires automatically (no close+reopen dance)

Alternatives considered (rejected)

Option	Why rejected
Switch ci.yml to pull_request_target	Exposes base-branch secrets to PR code — unsafe surface for test/lint jobs
Empty commit / close+reopen on each release	Manual toil per release; defeats the point of automation
Drop branch protection on master	Loses the safety net for human PRs too
Use a dedicated GitHub App	Heavier setup; PAT is sufficient for a single-maintainer repo

Test plan

• go vet ./... clean (no Go changes, just the workflow)
• CI on this PR runs the standard checks
• After merge + secret setup, manually run release.yml on master or wait for the next fix:/feat: to verify the next release PR has CI checks attached at creation time