Classify rebase failures for the ui_button_rebase UX SLI

What

Only unexpected / system rebase failures should count against the ui_button_rebase UX SLI error rate.

Previously RebaseWorker flagged every non-success result as an SLI error. Because expected user outcomes — chiefly merge conflicts — are the dominant failure, they formed a persistent ~20% baseline error rate that masked real infrastructure incidents (e.g. Sidekiq/Gitaly degradation did not move the error-rate needle).

How

• MergeRequests::RebaseService now categorises each failure and exposes it via #rebase_error_reason (:conflict, :source_branch_missing, :pre_receive, :command_error, :unknown). The execute return contract is unchanged — the reason is a sibling attribute of the existing #rebase_error, not a new result-hash key.
• RebaseWorker treats :conflict, :source_branch_missing, and :pre_receive as expected outcomes and no longer flags them as SLI errors. They complete as non-errors and feed apdex, so a handled-but-slow rebase surfaces as a latency violation rather than an error. Unexpected or unclassified failures still count as errors.

No user-facing behaviour changes (rebase works identically); this only adjusts UX SLI instrumentation, so no changelog entry.

References

• labkit-ruby discussion that prompted this: gitlab-org/ruby/gems/labkit-ruby!310 (comment 3533357114)

Closes #605652 (closed)