Fix cross-project cherry-pick branch collisions

What does this MR do and why?

Cross-project cherry-picks that start a new merge request generated their branch name against the source repository.

The branch can instead be created in the selected upstream project or, after authorization fallback, in the user's fork. A branch name that existed only in the actual destination therefore caused the operation to fail instead of selecting the next available generated name.

This merge request generates the branch name against the candidate destination before the branch-specific push check. If GitLab falls back to the user's fork, it generates the name again against that fork.

Redirects and success notices use the final selected branch name.

References

Resolves #629053 (closed)

Screenshots or screen recordings

Not applicable. This merge request does not change the visual interface.

How to set up and validate locally

1. Create an upstream project and a fork.
2. Create a cherry-pickable commit in the fork.
3. Confirm cherry-pick-<short-SHA> is absent in the fork.
4. Create that branch in the upstream project.
5. Cherry-pick the fork commit into the upstream project with Start a new merge request selected.
6. Confirm:
   • The existing upstream branch remains unchanged.
   • GitLab creates the next destination-unique generated branch.
   • The new merge request form uses that branch as its source.

Run the focused controller context:

bundle exec rspec spec/controllers/projects/commit_controller_spec.rb:319

Run targeted RuboCop:

bundle exec rubocop app/controllers/concerns/creates_commit.rb app/controllers/projects/commit_controller.rb app/models/commit.rb spec/controllers/projects/commit_controller_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.