ci: Mergify update rule reports a permanent red check on any PR that is behind and conflicting #3574

Problem

The Mergify rule added in #3563 — "Keep same-repository pull requests on develop current" (update: {}) — reports a red "Base branch update has failed" on any pull request that has fallen behind develop and conflicts with it.

update merges the base branch in. It cannot resolve a conflict; that is inherent to the action, not a misconfiguration. The rule already excludes conflicting PRs with -conflict, but the exclusion is evaluated when Mergify assesses the rule, and a conflict created by a develop landing in between still reaches the action.

Evidence

Observed 2026-09-25 on #3487 immediately after #3571 merged to develop:

Rule: Keep same-repository pull requests on develop current (update) — Base branch update has failed

Reproduced locally — the update is a plain merge, and it conflicts:

$ git merge origin/develop   # into fix/jest-ci-3479
Auto-merging CHANGELOG.md
CONFLICT (content): Merge conflict in CHANGELOG.md

Both sides had added an entry to the same [Unreleased] list. Mergify's documented failure text for this case is "merge conflict between base and head".

The rule was added in c396510544 (#3563) and had no merge to develop after it landed until #3571, so this was its first real execution. It fired and failed immediately.

Why it is not transient

This repo makes CHANGELOG.md a structural conflict point. The Require changelog or skip label gate demands a [Unreleased] entry on essentially every pull request, and every entry lands in the same short list. So while two pull requests are open, their changelog edits overlap by default, and whichever lands second guarantees a conflict for the other.

That makes "PR is behind and conflicts" the common case rather than the exception, so this rule will keep producing a red check on most stale pull requests. A human still has to merge develop in — which is what update would have done for them.

Impact

Low, and cosmetic. The active develop-branch-ruleset requires only three status checks:

• Route PR template and apply labels
• Validate changelog on PR
• actionlint

The Mergify check is not among them, so it never blocks a merge. The cost is a red X that trains reviewers to ignore a check, plus noise on every stale PR.

Options

Pick one; the first is the smallest.

• Drop -conflict from the conditions and accept the red check, documenting that a stale-and-conflicting PR needs a manual merge. Cheapest, honest, and stops pretending the rule covers cases it cannot.
• Narrow the rule so it never meets a conflict. The changelog gate means the conflict is usually only CHANGELOG.md. Mergify has no "update only if mergeable" condition, but the rule could be paired with a check that the PR is mergeable, or restricted to PRs that do not touch CHANGELOG.md.
• Resolve the changelog structurally so overlapping [Unreleased] entries stop colliding — for example a per-entry anchor or generating the section from merged PR metadata. This removes the root cause and helps the changelog gate generally, but is a much larger change and should be scoped on its own.
• Delete the rule. Once a merge queue or a strict required-check policy is in place the base does not need to be merged into the branch. fix(ci): Dependabot and Mergify configuration is stale and dependency PRs cannot auto-merge #3476 and ci(mergify): keep stale pull requests current with develop #3563 already discuss Mergify's role; worth revisiting there rather than here.

Acceptance

• Merging develop into a non-draft, non-fork pull request requires no manual step when the merge is clean
• A pull request that genuinely conflicts reports why, and does not present a permanently red check as if the automation were still working
• The chosen option is recorded in .github/mergify.yml comments, including the interaction with the changelog gate

Notes

Not a regression: the rule is new (#3563) and this is its first execution. #3487 needed a manual develop merge for the same reason and has since merged.

Relates to #3476, #3563, #1076.