Sort the rule builder's preview by count

Alphabetical order finds a payee you are already looking at, which is what the
list is for once a glob is typed. With the glob empty it answers a different
question -- what to write a rule for next -- and there the name is the least
useful thing about a row: one pattern claiming forty rows is worth more than
the first of forty claiming one, and nothing on screen said which was which
until you read the whole list.

ctrl+s switches between the two. A chord rather than a letter because the
builder is a form and every printable key belongs to the field being typed in;
the invariant that keeps q from quitting there cuts this way too. Ties fall
back to the alphabetical order so the list does not reshuffle when it is
rebuilt, and the cursor returns to the top, since the row under it is not the
row that was there a moment ago.

The header marks the column the order is read from, and the help names what the
key does next rather than where the list already is. The choice is the user's,
so it outlives the builder being left and reopened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -146,7 +146,9 @@ hand, while a narrower one is meant to take precedence and does.
 `Update` routes to `updateRules` / `updateTransfers` before `updateNormal`
 whenever the view is `viewRules` or `viewTransfers`, or typing `q` would quit
 and `i` would start an import. Any new full-screen input needs the same
-treatment.
+treatment. It cuts the other way too: a command *inside* a builder has to be a
+chord — `ctrl+s` re-sorts the preview — because every printable key belongs to
+the field being typed in.
 
 **In the rule builder, `tab` completes first and moves focus second.** The
 account and tag fields use `textinput.ShowSuggestions`, whose own `AcceptSuggestion`