Mint the release token with client-id, not the deprecated app-id

[178inaba]

Why

actions/create-github-app-token declares app-id as a formal deprecation in its action.yml — deprecationMessage: "Use 'client-id' instead." — so every run of this workflow emits an annotation. The step carried a comment saying the input stayed on purpose, but that reasoning was migration cost (the App and the APP_ID variable already existed), not design: with nothing to preserve, nothing argues for a deprecated input over the current one.

The reason to move now rather than when it breaks is when a removal would surface. This workflow only runs on push to main, so a Dependabot pull request bumping the action to a major that dropped app-id would run CI that never exercises it, merge green, and fail at the next release — with the tag already pushed and the least room to debug. .github/dependabot.yml runs the github-actions ecosystem weekly, so that pull request arrives on its own.

This is also a repair, not only an annotation cleanup. Both of the issue's manual steps are already done, ahead of what it assumed: APP_CLIENT_ID is set and APP_ID has been deleted. So main currently passes an empty app-id, and its next run — before this merges — would fail to mint a token. No run has happened since the variable was swapped, so nothing has failed yet.

What

One hunk in .github/workflows/release.yml:

• app-id: ${{ vars.APP_ID }} → client-id: ${{ vars.APP_CLIENT_ID }}
• Deleted the three-line comment that justified keeping the legacy alias — the replacement needs no note of its own

private-key is unchanged: the key is the same and the App does not need recreating. owner and repositories already read from the workflow context, so the file stays copyable to the sibling CLIs unedited.

Verification

This workflow cannot run on a pull request, so what is checkable here is limited:

• actions/create-github-app-token@v3's action.yml accepts client-id (required: false), fetched and confirmed at that ref
• gh variable list -R 178inaba/rdsh shows APP_CLIENT_ID holding the Iv23li… Client ID — not the numeric App ID — and no APP_ID
• go test -race ./... and the lint compose service both pass; yq parses the edited step

The issue's acceptance criteria — no deprecation annotation, tagpr still opening the release pull request as the App with a CI run and no manual approval — can only be observed on the first push to main after this merges.

Out of scope

178inaba/cflio still reads vars.APP_ID while its only repository variable is APP_CLIENT_ID, so its release workflow has the same gap. That migration is tracked in 178inaba/cflio#62.

Closes #70