Escape the merge conflicts view before prompting to continue the rebase

[stefanhaller]

When the last conflict of a file is resolved, a files refresh both offers to continue the rebase/merge (if we started it ourselves) and, via its merge-conflicts scope, escapes from the merge conflicts view back to the files context. The two race: the prompt is bounced onto the UI thread by the files worker, while the escape's context push is queued separately by EscapeMerge, and it deliberately refuses to push the files context over a popup. So if the prompt opens first, the escape does nothing, and closing the prompt lands the user in the stale merge conflicts view — usually already emptied by the escape's state reset — instead of the files panel. No later refresh rescues this.

Fix this by escaping from the merge conflicts view right before opening the prompt. This runs on the UI thread and doesn't hold the merge conflicts mutex, so it can reset the state and push the files context synchronously; whichever side runs first, the prompt now always opens on top of the files context, and EscapeMerge's guarded push still does nothing only when that's the right thing to do.

This is a timing race with no deterministic regression test; it showed up as a rare flake in tests that cancel the continue prompt (e.g. commit/amend_when_there_are_conflicts_and_continue) when looping the integration tests under the race detector.