jj fork: Commit subject lines rejects the merge commit GitHub's "Update branch" button creates

[andrewgazelka]

GitHub's "Update branch" button always produces a commit this repo's own PR check rejects

.github/workflows/pr.yml's Commit subject lines job enforces
/^.+:\s.+$/ on every commit a PR adds, with no exemption for merges:

// Ensure commit subject lines are in the form `area or areas: description`.
const subjectLineFormat = /^.+:\s.+$/;

GitHub's "Update branch" button writes Merge branch 'ix-patched' into <branch>,
which has no colon and therefore can never pass. Today that turned indexable-inc/jj#7 and #8
red the moment each was brought up to date, with a CHANGES_REQUESTED review:

The following commits do not follow our format for subject lines:

- e429ae18: Merge branch 'ix-patched' into views-cli-test

Nothing was wrong with either PR's content — both had just been updated onto a
green ix-patched tip. The red came entirely from the subject of a commit the
button generated. Both were then rebased instead, which drops the merge commit
and clears the check, so there is a working path; it just is not the one the
button offers, and the failure gives no hint that the button is the cause.

Worth noting the shape, because the two rules point in opposite directions for
ix-patched specifically: indexable-inc/index's packages/agent-prompt/ rules.nix says the branch itself is never rebased and that upstream arrives as
an ordinary two-parent merge. That is about ix-patched, not about PR branches,
so rebasing a PR branch is fine and there is no real contradiction — but an agent
reading "never rebase, merge forward" and then clicking "Update branch" lands
exactly here.

Desired outcome

Exempt merge commits from the subject check. This is a workflow bug, not a
documentation gap, and it should not be closed as one.

The rule exists because upstream jj reviews commits individually and never
squash-merges, so each commit's subject has to say what that commit does. A merge
commit is not that kind of commit — it carries no change of its own, and there is
no <topic> for it to name. So the check is asking a question the commit cannot
answer, and every merge commit in every PR fails it by construction.

Concretely: skip any commit with more than one parent, e.g. filter on
parents.length > 1 alongside the existing subjectLineFormat.test(s).

A note in CONTRIBUTING or the PR template is the strictly worse fix and worth
naming as such. It leaves a required check that a first-class GitHub UI button
always breaks, so it converts a bug into a piece of tribal knowledge every
contributor has to acquire by tripping over it once — and it does not help the
person who already pressed the button and is now staring at a CHANGES_REQUESTED
review about a commit they did not write. Documenting a trap is not the same as
removing it.

Filed here rather than on indexable-inc/jj because that repo has issues
disabled, and because the convention half of this lives in this repo's
packages/agent-prompt/rules.nix. The workflow change itself belongs in the
fork.

Filed by an agent after hitting it on indexable-inc/jj#7 and #8; unreviewed by
a human.