feat: cherry-pick a commit range from branch A onto a new branch C from the action bar

[angeousta]

Summary

This PR adds a new action-bar workflow: cherry-pick a range of commits from one branch (or ref) onto a brand-new branch, created off a separate base branch, entirely from the UI — no manual git checkout -b + git cherry-pick <range> + conflict babysitting required.

Concretely, given a source ref A, an optional older ref B on the same line of history as A, and a base branch D, this creates a new branch C off D and cherry-picks every commit in B..A (oldest first) onto it — skipping merge commits, which cherry-pick doesn't handle meaningfully as a "pick this one commit" operation.

Why

Grabbing a handful of commits from one branch and replaying them onto a fresh branch based on something else is a genuinely common Git workflow — pulling a few commits out of a stale or abandoned branch to revive them elsewhere, extracting part of someone else's work-in-progress branch to build on top of a different base, or re-basing a small slice of history onto a cleaned-up starting point. Doing this from the CLI means: figure out the right commit range yourself (git log, eyeballing SHAs), create the branch, run git cherry-pick <oldest>^..<newest>, and handle whatever conflicts come up one commit at a time with no preview of what's about to happen.

This PR moves that entire flow into the UI: pick the source, optionally narrow it to an explicit range, pick the base branch, preview exactly which commits are about to be replayed (see "commit range preview" below) — before anything touches the repository — and confirm. That preview step in particular addresses the main risk of the CLI version of this workflow: with git cherry-pick, you generally only find out what you actually picked after the fact (or by manually running git log yourself first); here you see the exact commit list up front and can back out before anything is applied.

What's included

Two commits, each a complete step:

1. Add cherry-pick branch A onto B as new branch C from the action bar, with explicit commit ranges — the core feature: a new action-bar entry and context-menu entry that open a dedicated prompt with three inputs (source ref A, range ref B, base branch D), validates that the range ref is actually an ancestor of the source ref before doing anything (rejecting empty or invalid/non-ancestor ranges up front rather than failing mid-cherry-pick), then creates branch C off D and cherry-picks B..A onto it oldest-first, skipping merges. Wires the new command through the state/effect layer (gitcomet-state) and the Git backend (gitcomet-git-gix), and adds an integration test suite covering the range cherry-pick behavior end-to-end.
2. Add commit range preview to the cherry-pick dialog — before confirming, the dialog now shows the actual list of commits that B..A resolves to (each with its short SHA, author, and summary), so the user can visually confirm "yes, these are the N commits I meant" instead of trusting a ref/range expression blindly. Preview rows are clickable to jump to and inspect that commit directly, for a closer look before committing to the action.

Relationship to other in-flight cherry-pick work

We're aware dev (or an open branch based on it) may also be moving in the direction of a more general interactive cherry-pick / rebase-sequencer UI for replaying individual commits via the commit editor. This PR is deliberately narrower and complementary rather than overlapping: it targets the specific "take a whole range from branch A and land it as a new branch off D" workflow, driven from the action bar / branch context menu, rather than a per-commit interactive sequencer. The two don't share UI surface or files as far as we can tell, but flagging it here in case there's a preferred direction to consolidate around — happy to adjust scope based on maintainer feedback.

Testing

• cargo check --workspace passes cleanly on the final state of the branch.
• cargo fmt --all -- --check passes cleanly.
• Git-backend integration tests: 5/5 passing (cargo test -p gitcomet-git-gix --test cherry_pick_integration cherry_pick_range), covering the range resolution, ancestor validation, and merge-commit skipping.
• State-layer tests: 7/7 passing (cargo test -p gitcomet-state cherry_pick), including the commit-range preview.

Notes for reviewers

This PR was prepared from a fork's branch that had diverged from dev for a while, and required adapting to a picker component (BranchRefPicker) that has since been superseded upstream — the ref-selection inputs in the cherry-pick dialog now go through the current branch_picker ref-row infrastructure instead, following the same pattern already used by create_branch_from_ref_prompt.

One thing worth calling out explicitly: while replaying the original commits from the source branch, several of them turned out to contain leftover, unresolved Git conflict markers in a handful of files — the residue of an unrelated local rebase on the source branch that had never been cleaned up before those commits were made. That's pre-existing content from the original branch, not something introduced while preparing this PR; it has been cleaned up as part of consolidating this history into the two commits above, so the code you're reviewing here is clean. One side effect: the first of the two commits is not independently buildable in isolation (the conflict-marker cleanup landed together with the second commit's changes) — only the branch's final state (both commits together) is guaranteed to build and pass tests. Happy to split this further or squash to a single commit if a cleaner shape is preferred for merging.

[Havunen]

@angeousta This feature looks interesting, yet I wonder is it important enough to reserve a space from the main action bar. Its also missing a name.

This is like automation flow - sort of.

The help texts need to be re-written so its easier to understand what it does.

Cancel button is not working

The branch picker really needs some tuning to make this functionality feel nicer. Also it would be good to be able to visualize what is going into the new branch that is created from here.

• Maybe this functionality should be rendered in dialog instead so there is more space for visualization.
• Maybe we should add a new button "Automations" to the actionbar that opens a menu where is a row to open this cherry pick flow.

We also need a better name for this functionality IMO

[angeousta]

@Havunen done