feat(workflows): let release-please act as a GitHub App

[davidmoralesz]

A release pull request opened with GITHUB_TOKEN triggers no workflows, so its required checks never report. Every release then needs the admin bypass or a close and reopen (seen on studiobimo/datapacks#15).

• release-please.yml: new optional input app-client-id and secret app-private-key. When the client ID is set, the job mints an app token with actions/create-github-app-token (contents and pull-requests write, calling repository only, revoked at job end) and release-please runs with it. Precedence is app token, then release-token, then GITHUB_TOKEN, so existing callers are unchanged.
• The token is minted inside the wrapper because a caller cannot hand one over from another job: a job output that holds a secret is dropped.
• README.md: the setup steps, and the one side effect to know about. A tag or Release made by an app does trigger other workflows, unlike one made with GITHUB_TOKEN. No consumer has an on: push: tags or on: release workflow today.

Still needed after this merges

1. Create the app, install it on the releasing repositories, and store RELEASE_APP_CLIENT_ID (variable) and RELEASE_APP_PRIVATE_KEY (secret).
2. Pass both from each caller's release.yml: project-template first, then the consumers.

Tested: the local hooks pass (actionlint, zizmor, pin check). Not tested: the mint step has never run, since no app exists yet. The fallback path is the unchanged expression with one more term in front; it is exercised by the next consumer release run after v1 moves.