tide: add configurable GitHub merge blocks enforcement

[Prucek]

Adds a new github_merge_blocks_policy configuration option that allows
Tide to check GitHub's mergeStateStatus to prevent merging PRs that are
blocked by GitHub due to branch protection rules, rulesets, required
reviews, etc.

The configuration can be set globally with '*' or per-org/repo level.
Defaults to "permit".
Valid values:

• "ignore": Ignore BLOCKED status entirely, attempt to merge anyway (risky)
• "permit": Allow merging but log warnings and show "In merge pool (despite BLOCKED)"
  status for monitoring. Use this to identify repos needing BP/ruleset fixes.
• "block": Respect BLOCKED status and prevent Tide from merging (safest)

Fixes #575, #269
Previous attempt: #537

🤖 Assisted by Claude.

[netlify]

✅ Deploy Preview for k8s-prow ready!

Name	Link
🔨 Latest commit	7f08e03
🔍 Latest deploy log	https://app.netlify.com/projects/k8s-prow/deploys/695bb5ce3822d50008705c92
😎 Deploy Preview	https://deploy-preview-579--k8s-prow.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Prucek
Once this PR has been reviewed and has the lgtm label, please assign petr-muller for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• pkg/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[petr-muller]

Thanks for following up on this! Opt-in config seems like a reasonable short-term way forward. Some thoughts (have not yet looked at the code):

I'm not sure I feel comfortable leaving default-configured (and even explicitly configured) instances vulnerable to the class of #269 -like bugs. Some repos may have policies that help them not getting affected by some instances of this problem but not necessarily to all, and the "tide silently fails to merge and never surfaces the problem" error is really annoying to leave some instances open to it. So to me it seems we'd still need to invent some way to propagate the actual merge failure, post-fact, to PR author somehow, I don't think we could consider #269 -like issues fully fixed 🤔

Configuration booleans are always a bit of a smell, for similar reasons like API Conventions states:

Think twice about bool fields. Many ideas start as boolean but eventually trend towards a small set of mutually exclusive options. Plan for future expansions by describing the policy options explicitly as a string type alias (e.g. TerminationMessagePolicy).

For this specific case, I think we may prefer treating this as a three-value for starters:

• ignore: ignore the BLOCKED entirely in decisions
• permit: merge BLOCKED PRs but make some noise about it, possibly in the log, possibly through some PR-exposed message like "In Merge Pool (despite BLOCKED)". This would be a good default to set us up for eventual flip the default to enforcing, because we'd help Prow and/or repo admins to monitor repos that either need BP/Ruleset fixes or explicit ignore/permit config
• block: respect BLOCKED

We'd start with permit as a default and possibly eventually flip the default to block?

[Prucek]

Thanks @petr-muller for the guidance! That is definitely a good point. I updated the PR based on your comments.