rebase_merge_request wait=true: first poll can read pre-rebase state, reporting head_changed=false #864

Follow-up to #862 (and #844).

In E2E verification of #862, 2 of 6 runs reported the rebase as finished while sha was unchanged, returning head_changed=false. The other 4 runs returned head_changed=true with a new sha.

Likely cause: the first status poll right after requesting the rebase can read the MR state from before the rebase started (possibly gitlab.com latency). This race already existed with wait=true from #844; the new head_changed field can surface it as a wrong "head did not move" answer.

Proposed hardening: when the first poll reports finished but the sha equals previous_sha, poll a few more times (short backoff) before concluding head_changed=false.