Edit a rule from the rules screen

A rule could be written and deleted but never changed, so fixing a glob meant
deleting the rule and typing it again -- losing its note, the comments around
it, and its position, which still breaks ties between equally specific rules.
e now opens the selected rule in the builder and enter rewrites it where it
sits. config.ReplaceRule edits rules.toml textually, as deleting does, and
keeps the comments above the rule: they say why it is there, which editing its
glob rarely changes.

The round trip must not lose what the form does not show. The builder has four
fields and a Rule has five, so an edit carries the type pattern through
untouched and says so under the glob; a type-only rule saves without one. The
preview needed the same care in reverse: a working rule's transactions are
tagged, so an untagged-only preview would be empty for it. Its own rows are
added back, and the ones a narrowed glob stops catching stay on screen marked
-- giving one up is the decision being made, and it must not happen silently.

The builder and its list shared one return view, so opening the builder from
the list left esc pointing back into the form. Each screen now remembers its
own way out; transfers had the same trap and the same fix.

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

README.md

@@ -189,6 +189,27 @@ because the more specific rule wins. Legs of a matched transfer are left out
 too: they are already accounted for by the definition that paired them, and the
 report leaves them out anyway.
 
+#### Editing a rule
+
+`e` on the rules screen (`5`) opens the selected rule in this same form with the
+fields filled in, and `enter` rewrites that rule where it sits instead of
+appending a new one. It keeps its position, since position still breaks ties
+between equally specific rules; `rules.toml` is edited textually, so the
+comments and formatting around it survive, exactly as when deleting.
+
+An edit is judged against different rows to a new rule. What the rule already
+claims is tagged, so none of it would be in an untagged preview and a rule that
+works perfectly would preview as nothing; those rows are put back, and any the
+new glob stops catching stays on screen marked `−`, under a "*n* no longer
+claimed" line, rather than quietly disappearing the way an ordinary non-match
+does. Narrowing `*LIDL*` to `*LIDL SOFIA*` therefore shows you the Varna branch
+you are about to hand back to whatever rule catches it next.
+
+The form has no `type` field, so a rule that sets one carries it through
+unchanged rather than losing it; it is shown under the glob as `+ type:… ·
+kept`. Saving lands back on the rules screen with the new counts, and `esc`
+leaves the rule as it was.
+
 ### Rules (`5`)
 
 Every rule in file order — the order they are written in, not the order they
@@ -215,14 +236,16 @@ deleting. Note that shadowing has nothing to do with the numbering: rule 2 would
 be just as dead written above rule 1, because precedence is decided by how
 specific a rule is and not by where it sits.
 
-`d` deletes the selected rule, `p` deletes every rule marked `✗` at once, and
-both ask for a `y` first. `r` recounts against what is currently in the index,
-which is what you want after an import has added rows; `rules.toml` itself is
-read at startup and whenever you save a rule from the builder, so an edit made
-in another window needs a restart. Deleting edits `rules.toml` textually, so your
-comments, ordering and formatting survive; a comment sitting directly above a
-deleted rule goes with it, while one separated by a blank line is treated as a
-section heading and left alone.
+`e` opens the selected rule in the builder to edit it, `d` deletes it, and `p`
+deletes every rule marked `✗` at once; both deletions ask for a `y` first. `r`
+recounts against what is currently in the index, which is what you want after an
+import has added rows; `rules.toml` itself is read at startup and whenever you
+save a rule from the builder, so an edit made in another window needs a restart.
+Editing and deleting both work on `rules.toml` textually, so your comments,
+ordering and formatting survive. A comment sitting directly above a deleted rule
+goes with it, while one separated by a blank line is treated as a section
+heading and left alone; an edited rule keeps its comments, since they say why it
+is there and changing its glob rarely changes that.
 
 ### Transfer builder (`6`)