docs(workflow): mergify now stops a label loop, the page said it ran indefinitely

[mergify-ci-bot]

The label action page warned that a pair of rules flipping the same label
makes it "toggle back and forth indefinitely". The engine no longer lets that
happen: it counts the reversals of a label made by rules undoing each other
and, past a threshold within a short window, stops changing that label on that
pull request in either direction until the repository's Mergify configuration
changes, reporting a failing check run that names the label and the rules.

So the old text was wrong twice over. It overstated the symptom, and it left
out the consequence a reader now actually has to plan for: the label stops
following the pull request's state until the configuration is fixed, which is
a different failure mode from a label that flaps. The advice to make the
conditions mutually exclusive is unchanged and still the real fix, so it stays
— now framed as the fix rather than as the only thing standing between you and
an endless loop.

Evidence: the label loop guard in the engine, which derives the history from
the pull request's own action.label events and emits the
action.label.loop_stopped event that appeared in public/api-schemas.json
this window; only rule-made changes count, so a command or a built-in rule
does not trigger it.

Open question: whether the exact threshold belongs in the prose. The engine
stops the label after a fixed number of reversals within a fixed window, and I
wrote that as "enough times in quick succession" rather than giving the two
figures, because they are tuning constants picked from production measurement
and publishing them invites configurations tuned to sit just under them. If we
would rather be precise, both are in the engine's label loop guard and the
sentence takes them without restructuring.

[mergify]

Merge Protections

🔴 2 of 5 protections blocking · waiting on 👀 reviews

	Protection	Waiting on
🔴	👀 Review Requirements	👀 reviews
🔴	🔎 Reviews	👀 reviews
🟢	Enforce conventional commit	—
🟢	📕 PR description	—
🟢	🚦 Auto-queue	—

🔴 👀 Review Requirements

Waiting for

• #approved-reviews-by >= 1

This rule is failing.

• any of:
  • #approved-reviews-by >= 1
  • author = dependabot[bot]
  • author = renovate[bot]
  • all of:
    • -head ~= ^docs-agent/
    • author = mergify-ci-bot

🔴 🔎 Reviews

Waiting for

• #review-requested = 0

This rule is failing.

• #review-requested = 0
• #changes-requested-reviews-by = 0
• #review-threads-unresolved = 0

---

Show 3 satisfied protections

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:

🟢 📕 PR description

• body ~= (?ms:.{48,})

🟢 🚦 Auto-queue

When all merge protections are satisfied, this pull request will be queued automatically.

[mergify]

@mergify-ci-bot this pull request is now in conflict 😩

[mergify-ci-bot]

🤖 Everything this pull request still changed is already on main, or has moved to a pull request of its own — so there is nothing left here to publish. Closing it rather than push an empty revision.

workflow/actions/label.mdx now matches main byte for byte, so there is
nothing left here to propose: #13255 landed the same correction on 7 October by
a more precise route. Where this branch said Mergify stops the loop "enough
times in quick succession", main names the mechanism and the numbers — a
reversal counts only when it undoes Mergify's own previous change of that label
and comes from a different rule, and the tenth such reversal within an hour
stops the label in either direction until the configuration changes.

That also settles the open question this pull request left open, whether the
threshold belonged in public prose: it is published, and I have not tried to
take it back out. The only thing this branch still had of its own was an inline
link to how rules are evaluated, which is not a reason to keep it open. I
resolved the conflict in favour of main, which leaves the branch empty.