bug: cherry-pick labels re-added to already cherry-picked PR, triggering duplicate cherry-pick PRs

[prabinovRedhat]

Description

When a PR that has already been successfully cherry-picked to release branches has its cherry-pick labels re-added (e.g. via API/automation), the webhook server creates new duplicate cherry-pick PRs — even though the original cherry-picks already exist.

Steps to Reproduce

1. PR #369 was merged to main with cherry-pick labels for v2.10 and v2.11
2. Cherry-pick PRs were successfully created: #382 (v2.11) and #383 (v2.10)
3. The cherry-pick labels were accidentally re-added to the original PR support push new container on each release - 368 #369 (via AI tooling attempting to fix the needs-rebase state on the existing cherry-pick PRs)
4. The webhook server created new duplicate cherry-pick PRs: #385 (v2.11) and #386 (v2.10)

Expected Behavior

The webhook server should detect that cherry-pick PRs already exist for the given target branches and not create duplicates. It could either:

• Skip creation and comment that a cherry-pick PR already exists for that branch
• Or reject the label addition entirely

Actual Behavior

New cherry-pick PRs are created unconditionally whenever cherry-pick labels are added, without checking for existing cherry-pick PRs targeting the same branch from the same source PR.

Impact

This creates duplicate PRs that need to be manually closed, adding noise and confusion for reviewers.