"still unresolved conflicts" may not show expected "next" conflict

[abrenneke]

Occasionally I run into this. It usually happens when I have a megamerge, and I rebase all branches onto the trunk after fetching. I'll end up with a bunch of conflicts in the branches, and in the merge.

Upon fixing one of the conflicts and squashing into the revision, something like this happens:

In particular, it says:

There are still unresolved conflicts in rebased descendants.
Hint: To resolve the conflicts, start by creating a commit on top of
the conflicted commit:
  jj new z

However, the "next" conflict I need to address is actually pux in this case. An ancestor of z.

Relevant discord discussion

Should report_repo_conflicts have something like the following logic in addition to the current logic?

if next found conflict has conflicted ancestors, report those first

Arguments for:

• I tend to fix all conflicts at once. It's useful for the terminal output to mention the "next" thing I need to fix.
• Fixing z first may just mean you have to repeat the same conflict resolution in pux, which may again conflict z.

Arguments against:

• pux is unrelated to the revision I just fixed, lw.
• The pux conflict happened before I changed lw, so is irrelevant to the "squash" operation I just performed.