ci: Increase retry count on PR conflict check

[QuLogic]

PR summary

We currently have enough open PRs with conflicts that the automated labels are no longer being added.

For example, #25787 had conflicts when #25607 was merged, but the logs show it was not ever considered as the action had only reached up to #22678. (Also, it was rebased before that could happen due to the action's retry delay, but the important thing is that the action didn't get to it yet.)

PR checklist

• [n/a] "closes #0000" is in the body of the PR description to link the related issue
• [n/a] new and changed code is tested
• [n/a] Plotting related features are demonstrated in an example
• [n/a] New Features and API Changes are noted with a directive and release note
• [n/a] Documentation complies with general and docstring guidelines

[QuLogic]

For reference, the default is 5 retries with 2 minutes delay, so we are unfortunately already taking 10 minutes for this, and this bump would make it up to 20. Really it just means we need to go take a look at the blocked PRs.

[ksunden]

I'm fine with upping the limit, but its not actually obvious to me that that will have any effect... from looking at the logs, it looks like each retry restarts at the beginning and so it's not like doing it 5 more times will actually do anything.

[ksunden]

From the docs, the purpose of "retryAfter" is not to get more coverage, but rather to give GitHub time to calculate if the PR is mergable

But after looking a bit more carefully at the logs with that in mind, that does actually seem to be the limiting factor here, not e.g. number of actions.

So I think that is based on number of open PRs, not necessarily ones with label (it needs to check the ones that don't have a label to see if it newly needs it) But that doesn't explain why this is a new problem (well, I guess I don't know for sure that we would for sure notice super quickly)

[oscargus]

Let's if it improves the situation.