Context

We have decided that we will implement a new PR life cycle when conflicts are detected:

• Empty PR opens
• Comment like this is dropped with instructions for user
• User resolves conflicts locally and pushes branch back
• Regular PR life cycle resumes

This issue is about making sure the state machine handling the PR understands what's happening to the PR

Goal

• For subscriptions with a given feature flag on, turn on the new behaviour.
• This means creating an empty PR with the new comment dropped.
• Then the PR needs to stay unmergeable until codeflow metadata matches what is expected.
• New updates to the PR should stay blocked until user pushes the correct state.
  • This is questionable - maybe we could be dropping new comments and expect user to call the command with the latest build ID - that should work but see how it behaves.
• New updates causing a conflict should kickstart the same flow again mid-PR.