feat(pull): add bypass-rules opt-in and expose scheduled auto-merge via API

[bircni]

Reworks the pull request merge box to match GitHub's behaviour and surfaces auto-merge state on the API.

Merge box

• Bypassing branch protection is now an explicit, red "Merge without waiting for requirements to be met (bypass rules)" checkbox above the merge button, instead of a silent, automatic force-merge for admins.
• With unmet requirements and no bypass, the default action is now Enable auto merge — so admins (and bypass-allowlisted users) can schedule an auto-merge, not only force-merge.
• Ticking bypass switches to an immediate merge (button turns red); the two are mutually exclusive, so force_merge and merge_when_checks_succeed are never both sent.
• The merge-style dropdown now only selects the style and is hidden when a single style is allowed. The button and the pending-schedule notice name the style (e.g. "Enable auto merge (squash)").

API

• PullRequest responses gain a GitHub-compatible auto_merge object (enabled_by, merge_method, commit_title, commit_message), or null when not scheduled — on both the single-PR and list endpoints (batched to avoid N+1). Swagger regenerated.

Screenshots

[wxiaoguang]

TBH, the checkbox UI/UX seems strange. Personally I am used to the old UI.

I prefer to keep the UI concise, avoid unnecessary interactive components when end user doesn't really need it.

---

That's just my opinion, just FYI. If most people like the new UI, I am neutral

[wxiaoguang]

TBH, the checkbox UI/UX seems strange. Personally I am used to the old UI.

Or, if the "bypass" decision is not made by a checkbox, but by a secondary "toggle link/button" like "Switch to auto merge / Switch to force merge", maybe the UI would look better.

[bircni]

Thanks @wxiaoguang for the response - i will take a look at it
Finally anyone who cares <3

[bircni]

@wxiaoguang changed it to this:

[wxiaoguang]

@silverwind what do you think about the new UI?

• If you like or are neutral: continue
• If you don't like but wont' block: continue
• If you would block: please suggest

[bircni]

ping @silverwind

[silverwind]

Looks ok but I would do something to align the button colors of the merge box with github, they only have two states, uncolored and green. Those red/blue buttons confuse me and their meaning is not really conveyed.

Whether the primary action is green or primary (blue) I don't really care but I guess for consistency it should remain blue.

[silverwind]

Also I think the merge button should be last section in the box, e.g. move the command line instructions besides it, similar to GitHub:

[bircni]

I think we should keep the red color if you are doing something "bad" (bypass merging)

[bircni]

@silverwind @wxiaoguang ping

[wxiaoguang]

@silverwind @wxiaoguang ping

Is silverwind happy with it now?

[bircni]

I'd still prefer the same ui as GitHub has with the checkbox but I am also fine with this solution

[silverwind]

I guess I need to take a look at this UI myself. This stray red text looks confusing. The whole merge box is full of confusing UI, I prefer a re-alignment with GitHub.

[bircni]

I guess I need to take a look at this UI myself. This stray red text looks confusing. The whole merge box is full of confusing UI, I prefer a re-alignment with GitHub.

restyled it again

[wxiaoguang]

I don't think it is a right design.

The pullMergeBoxInfoItemCollection is designed to be a flat list. Now, you just added the hacky patches to make it "indented" and "grouped".

It is very fragile.

I believe that "don't try to teach a duck to bark to make it become a dog".

If you need a new layout, design a proper data structure for it. Complex changes can be in a separate and dedicated PR.

[wxiaoguang]

It seems working because at the moment all callers to AddErrorItem are on infoProtectionBlockers, then the design is abused by this PR.

But indeed AddInfoItem / AddErrorItem are similar functions, the layout will break if AddInfoItem / AddErrorItem are both called for the same section.

We should avoid the unclear and fragile behaviors when designing the functions and methods. Do not bring surprises to developers.