fix: has-conflicts label flaps when mergeable status is None

[rnetser]

Summary

The has-conflicts label is incorrectly removed when pull_request.mergeable returns None (GitHub still computing merge status). This causes label flapping — the label gets removed and re-added repeatedly.

Problem / Motivation

In label_pull_request_by_merge_state() (pull_request_handler.py line 966-967):

mergeable = await asyncio.to_thread(lambda: pull_request.mergeable)
has_conflicts = mergeable is False

When mergeable is None, has_conflicts evaluates to False, causing the code to remove the has-conflicts label at line 982-984 even though the PR may actually have conflicts — GitHub just hasn't finished computing.

Impact

Observed on RedHatQE/openshift-virtualization-tests#3031 — 120 label events (add/remove) across 47 days from multiple bot instances racing to check merge status.

Requirements

1. When mergeable is None, skip the label update entirely and return early
2. Only act when mergeable is explicitly True or False

Deliverables

• Skip label update when mergeable is None in label_pull_request_by_merge_state()
• Add test case for mergeable=None scenario
• Update CLAUDE.md (if applicable)

Notes

Fix should be a simple early-return guard at the top of the merge-state labeling logic.