feat: define and implement merge conflict detection + handling workflow

[biz-biz-Bot]

Problem

Open PRs can develop merge conflicts as main advances, and there is currently no automated detection or handling process. Conflicts were discovered manually on PRs #305, #329, #332, #335, #342, #344 — but nothing surfaced them proactively.

Related

The PR watcher (#350) fires on GitHub review events (comments, approvals). Merge conflicts are a different signal — they appear in a PR's mergeable / mergeability_reason fields on the GitHub API. The two concerns are orthogonal; #350 does not cover this.

Questions to resolve

1. Who detects conflicts? Should the PR watcher also poll mergeable state? Or a separate scheduled job?
2. Who resolves them? Smith should rebase or merge main into the branch, then push. When should this happen — on a schedule, or reactively on conflict detection?
3. Does resolution require re-review? If the rebase changes the diff non-trivially, the assay review-loop should re-run before the PR is considered ready.
4. What happens after merge conflicts are resolved? Labels updated, PR watcher notified?

Proposed approach (to be confirmed)

• PR watcher (or a sibling sentinel job) polls mergeable for open PRs labeled agent-ready-for-review or agent-in-progress
• On conflict detected: assign to Smith (label swap), Smith rebases + pushes
• If diff changed: re-run run-review-loop.sh; proceed on APPROVED
• Label back to agent-ready-for-review when clean

Definition of Done

A conflict on an open PR is detected automatically and resolved without manual intervention.