Ignore branch-ref decorations on merge commits when extracting issue keys

[RomainCscn]

Problem

linear-release sync attached an issue (ACME-7) to a release though it appeared in no commit body and had no merged PR.

Why: the CLI reads issue keys from branch names, deriving the branch from git's %D ref decorations. A branch (ACME-7) created from an in-range commit but never committed onto still has its ref pointing at that commit. With fetch-depth: 0 the decoration is present, so the key leaked off the down-merge commit it was cut from.

Fix

A ref on a merge commit is the mainline or a stale branch cut from it — never the work itself, and its branch name comes from the merge message anyway. A ref on a regular commit may be the only key source (GitLab fast-forward / direct push). So: read decorations only on regular commits.

const isMerge = parents.length >= 2;
const branchName = extractBranchNameFromMergeMessage(message) ?? (isMerge ? null : extractBranchName(rawDecorations));

Scenario (fixed)

commit	kind	label	before	after
Down merge trunk into release (#101)	merge	ACME-7 (stale ref)	ACME-7 leaks ❌	ignored ✅
[ACME-3] fix lookup (#102)	regular	—	ACME-3 (from message)	ACME-3 ✅

Regular-commit decorations still work, so GitLab fast-forward features (key only in the branch name, on an interior commit) are preserved.

Tests

382 passing. New describe "branch refs decorating interior commits": negative (stale ref on an interior merge → branchName null) + positive (FF feature on an interior regular commit → branch name kept — the coverage gap that let the original behavior regress).

Fixes LIN-75064

[linear-code]

LIN-75064