bot-token, merge-key-check, notify-umbrella and gemini-review on marola-pr-bot (MIP-0086 row 2)

[brunogbv]

Summary: The devkit side of MIP-0086's two Apps. A bot-token composite action mints a scoped marola-pr-bot or marola-merge-bot token for named repos, merge-key-check keeps the merge bot's key out of jobs that run third-party code, and notify-umbrella and gemini-review move to the PR bot with the old names as fallback. Closes #79.

MIP	MIP-0086 §5.4 to §5.6, tasks row 2
Tested	✅ gates · ⬜ e2e · ✅ live · ⬜ ci-only: release.py and merge_key_check.py self-tests red then green; actionlint; devkit quality gate run outside Nix (ruff 0.17.0 from a venv, flake.nix unevaluated). Live: bot-token test passed against the real PR_BOT_KEY on the final head in run 38465551179.

What changed

• release.py moves marola-dev/marola-devkit/.github/actions/<name>@vX.Y.Z pins, so consumers' bot-token pin follows a release.
• .github/actions/bot-token: mints with an explicit repo list under owner: marola-dev. It refuses an empty or malformed list (the token action reads "\r\n" as no list, which would cover every installed repo) and a call with no permission-* set (which would inherit every permission the App holds). The bot's git identity goes to a gitconfig under $RUNNER_TEMP, exported as GIT_CONFIG_GLOBAL, so it ends with the job even on a self-hosted runner.
• .github/workflows/bot-token-test.yml: the refusals, then a token for marola-devkit with contents: write only. It must list exactly that repo, get 403 on pulls, succeed on a git push --dry-run to marola-devkit and be refused (403) on one to marola-site, and commit as <id>+marola-pr-bot[bot]. A {} POST to git/refs is not used: it returned 422 on marola-site as well, so it shows nothing about permission.
• scripts/merge_key_check.py, in just quality, tests/self-tests.sh and the flake's tools: MERGE_BOT_KEY (matched case-insensitively, as GitHub resolves secret names) may appear only in workflows listed in .github/merge-key-allowlist. A keyed job fails on a third-party action, a reusable call other than a listed local one receiving the key under its own name, container/services, a shell other than bash or sh (step or defaults), workflow-level env carrying the key, or nix/npm/pip/curl and the like in run:. Once the allowlist exists, secrets: inherit fails in every workflow of the repo.
• notify-umbrella takes pr_bot_key and mints an umbrella-only Contents-write token; the token PAT is read only when pr_bot_key is absent.
• gemini-review reads PR_BOT_* first, GEMINI_* second; GEMINI_APP_PRIVATE_KEY is no longer required.
• Docs: marola-gemini-bot is marola-pr-bot in present-tense prose; the action, the check and pr_bot_key are in the reference pages; gemini-review's caller example passes secrets explicitly; one line in the unreleased v0.9.0 CHANGELOG entry.

No consumer breaks at its next pin bump: callers passing only token, or GEMINI_* secrets, behave as before.

What this leaves for later rows: merge-key-check blocks secrets: inherit in any repo holding the merge key, so marola-dev/marola#766 (row 4) and #80 (row 8) must switch their gemini.yml to explicit secrets before adding an allowlist. The check reads workflows only; a checked-in script that itself runs nix or curl is outside what it can see.

This branch and mip-0086/3-merge-bypass both add a line to the v0.9.0 CHANGELOG entry; whichever merges second rebases.