[BUG] Label workflow strips has-conflicts when mergeability is unknown #2025

Problem

The label workflow removes has-conflicts from PRs that still have merge conflicts.

Context

All open PRs are affected when GitHub has not yet computed mergeability. This happens often after a push to main. A PR with conflicts gets no merge-ref CI run, so its required checks are missing. The workflow reads this as "CI pending" and runs the branch that logs stripping state labels. That branch removes every state label, and has-conflicts is one of them.

The early conflict check only matches mergeable === false && mergeable_state === 'dirty'. When GitHub returns null or unknown, the check falls through to the CI branch. The unknown-mergeability handling comes after the CI branch, so it never runs for these PRs.

The old single concurrency group hid this. Most PRs were not reconciled. After #1739, the sweep reaches them. In one hour has-conflicts fell from 83 to 30 labels. I tested 5 of the PRs that lost the label with git merge-tree against main. 4 still conflict (#934, #300, #1015, #1785).

Reproduction steps

1. Open a PR that conflicts with main, with required checks missing.
2. Make GitHub report mergeable: null (push to main, then run the workflow before GitHub recomputes).
3. Run the "Label PR review state" workflow for the PR.
4. Read the job log. It says CI pending — stripping state labels. The PR loses has-conflicts.

Expected result

The PR keeps has-conflicts while mergeability is unknown.

Actual result

The PR loses has-conflicts. The conflict signal disappears.

Proposed fix

When mergeability is unknown and the PR already has has-conflicts, keep the label through the CI branch. When mergeability is known and not dirty, keep the current behavior. Add tests for the unknown, known-clean and known-dirty cases.

File: .github/workflows/label-pr-review-state.yml. Tests: src/services/__tests__/pr-review-state-workflow.test.ts.