ci: release-please PRs never run CI (action_required), so releases merge unverified

[amondnet]

Problem

ci.yml triggers on every pull_request, but it has never actually run on a release-please PR. All four CI runs on release-please--branches--main are completed / action_required:

$ gh run list --branch release-please--branches--main --workflow ci.yml
CI [pull_request] completed/action_required 35382c9   <- the v0.1.0 release PR
CI [pull_request] completed/action_required 11b8e8b
CI [pull_request] completed/action_required 77eedc2
CI [pull_request] completed/action_required cefb345

The repo's contributor approval policy requires approval for first-time contributors:

$ gh api repos/pleaseai/openhwp/actions/permissions/fork-pr-contributor-approval
{"approval_policy":"first_time_contributors"}

and the release PR's triggering actor is github-actions[bot] — .github/workflows/release-please.yml passes no token:, so release-please runs with the default GITHUB_TOKEN.

Dependabot PRs are unaffected (#3/#4/#5 all show CI completed/success); Dependabot has its own trusted lane.

Impact

Release PRs reach a merge-ready state without check or smoke ever running. The green checks on #2 came only from GitHub Apps (CodeQL, SonarCloud, Socket), which are not subject to the approval gate — so the PR looks verified while the repo's own type-check, lint, format check, and headless editor smoke test never executed.

For v0.1.0 this was worked around by checking out the release SHA locally and running deno task check, deno lint, and deno fmt --check by hand (all passed) before merging. That should not be a per-release manual step.

Options

1. Give release-please a non-default token — a GitHub App installation token or PAT via the action's token: input. The PR is then authored by that identity and its workflows run normally. This is the standard workaround for GITHUB_TOKEN-authored PRs and addresses the root cause.
2. Relax the approval policy to first_time_contributors_new_to_github (Settings → Actions → General).
3. Approve each run manually in the Actions tab on every release PR — no config change, but a recurring manual step that is easy to forget.

Option 1 is preferred: it keeps the gate intact for genuine external contributors while letting the repo's own release automation be verified.