Name the branch a merge is made into

[ameyypawar]

🧠 Changes

The merge commit written when updating the workspace with the merge strategy now names the branch it is merged into. A managed workspace's head is the lane's own reference; a direct checkout has the checked-out branch, which is preferred over any other reference sitting on the same commit. A head that nothing names states only what was merged, rather than inventing a name.

☕️ Reasoning

The message was format!("Merge {} into merge", ...), with merge a literal rather than the branch. Four committed snapshots in upstream_integration.rs carried it, including (HEAD -> A) Merge refs/remotes/origin/main into merge, where the branch is plainly A on the same line. Those snapshots are the regression test: they now read into E and into A, and the only shas that move are the merge commit and its sole descendant.

Preferring the checked-out branch matters for a direct checkout, where the head is a commit rather than a reference. Walking to the nearest reference finds every branch on that commit, and step_references() makes no ordering promise, so a second branch sitting on the tip could just as well have been named.

Two notes on what this does not do:

• The target keeps its full ref name, as in the original report's expected output. Shortening it to origin/main would read closer to git merge, but that is a separate decision about the whole message.
• plan.rs's Merge {commit_id} into previous commit is the same kind of placeholder on the per-branch integration path, and is left alone here.

One case has no test: a direct checkout with a second branch on the head commit, where the checked-out branch has to win. These tests build their graph from explicit tips, so an extra reference never reaches the code under test. I wrote that test, found it passed against the old behaviour too, and removed it rather than leave an assertion that proves nothing.

🎫 Affected issues

Fixes: #5748