feat(cursor-review): optional dedicated bot identity for review posting (BE-1812)

[mattmillerai]

Implements BE-1812 (hunks 1+2 of the BE-1800 approach): the cursor-review reusable workflow can post under an optional dedicated bot identity instead of the shared github-actions[bot], so its review threads become distinct and queryable.

Change — one file, .github/workflows/cursor-review.yml

1. Two optional workflow_call secrets: BOT_APP_ID, BOT_APP_PRIVATE_KEY (both required: false).
2. A Detect bot identity step + a conditional actions/create-github-app-token@v2 mint step before Post review.
3. Post review's token becomes ${{ steps.bot_token.outputs.token || secrets.GITHUB_TOKEN }}.

post-review.py is untouched — the comment author follows whatever token it gets.

Note: secrets can't be referenced in a step if:, so a tiny Detect bot identity step surfaces presence as a step output the mint step gates on (actionlint-clean).

Safe to merge now (red-safe / no-op until configured)

With no creds supplied, the mint step is skipped and posting stays github-actions[bot] — zero behavior change for every consumer, including OSS callers. It posts under the new identity only once the App + org secrets exist (BE-1813) and callers pass them through (BE-1814).

Two usual footguns were already handled here, so no companion edits:

• Dedup keys on the review body marker, not the author — identity change won't re-trigger reviews.
• Triggerer attribution already falls back to the PR assignee on a bot actor — Slack DM attribution survives.

Pin style matches the file (bare tags). Caller passthrough is the separate BE-1814.

Refs BE-1812 · parent BE-1800.

[coderabbitai]

Warning

Review limit reached

@mattmillerai, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 40 minutes and 48 seconds. Learn how PR review limits work.

To continue reviewing without waiting, enable usage-based billing in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 53471e18-6330-4f3e-a325-68fa0d904dba

📥 Commits

Reviewing files that changed from the base of the PR and between 31a2c3e and f4427a4.

📒 Files selected for processing (1)

• .github/workflows/cursor-review.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-1812-story-11-cursor-review-reusable-workflow-optional-dedicated

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-1812-story-11-cursor-review-reusable-workflow-optional-dedicated

---

_{Comment @coderabbitai help to get the list of available commands.}