fix Dependabot review cleanup concurrency

[Pigbibi]

What changed

• dismiss Pigbibi review requests automatically generated for Dependabot PRs
• recognize both dependabot[bot] and app/dependabot identities
• require the review-request event actor to be Dependabot
• re-check the latest Pigbibi review-request actor from the PR timeline immediately before deletion
• preserve later or concurrent review requests made by maintainers
• keep concurrent review-request runs instead of cancelling the matching cleanup
• use pull_request_target with metadata-only GitHub API access and no checkout

Why

These repositories already auto-merge eligible non-major Dependabot updates after CI, but CODEOWNERS creates redundant review notifications. Event-actor and timeline checks let the workflow remove only bot-generated requests without touching human review requests, including race conditions while a run is queued.

Validation

• verified automatic CODEOWNERS timeline actor on a historical Dependabot PR
• verified both supported Dependabot identities
• verified requested reviewer, event actor, and latest timeline actor conditions
• verified API errors fail instead of being treated as no match
• verified no checkout or execution of PR code
• bash syntax check
• git diff --check

[github-actions]

🤖 Codex PR Review

✅ Merge allowed: 1 finding(s) reported but none are blocking

ℹ️ Other Findings

1. 🟡 [MEDIUM] Logic in .github/workflows/dependabot_review_request_cleanup.yml

The new gh api check only inspects the first 100 timeline events (?per_page=100) when deciding who made the latest Pigbibi review request. If the pull request has accumulated more than 100 newer timeline entries before this queued cleanup job runs, the most recent matching review_requested event can fall off the page, latest_request_actor becomes empty, and the workflow exits without deleting a Dependabot-created request. This is reachable on long-lived or noisy PRs because this workflow now serializes runs instead of cancelling them, so a cleanup job can execute well after the triggering event. (line 39)

Suggestion: Fetch all pages before computing the last matching event, for example by using gh api --paginate on the timeline endpoint, or query a source that can reliably return the current requested-reviewer state without a fixed page cap.

---

Review by Codex PR Review bot • PR