Add a rules screen that finds and removes dead rules

Nothing showed whether a rule was still earning its place. The new screen, on
5, lists every rule in file order with the number of transactions it claims,
marking those that claim none.

The count comes from Engine.Usage, which counts by first match, so a rule
shadowed by an earlier one reports zero even though its glob matches. That is
the case worth catching: such a rule looks correct in isolation and can never
fire.

d removes the selected rule and p removes every unused one, each behind a y/n
confirmation since this rewrites a hand-maintained file. config.DeleteRules
edits rules.toml textually rather than re-serialising the parsed rules, so
comments and layout survive; a comment directly above a rule goes with it,
while one separated by a blank line is left as a heading. The result is
re-parsed before it replaces the file.

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

CLAUDE.md

@@ -55,6 +55,18 @@ rule builder cannot shadow a rule the user wrote by hand.
 `viewRules`, or typing `q` would quit and `i` would start an import. Any new
 full-screen input needs the same treatment.
 
+**A rule's usage count is how many transactions it wins, not how many its glob
+could match** — `Engine.Usage` counts by `MatchIndex`, so a rule shadowed by an
+earlier one correctly reports zero. That is what makes the rules screen able to
+find dead rules at all.
+
+**`config.DeleteRules` edits rules.toml textually, never by re-serialising the
+parsed rules**, because comments and formatting are not recoverable from
+`[]Rule`. A rule owns the comment lines directly above it; a comment separated
+by a blank line is a heading for what follows and stays. Both writers go
+through `writeFileAtomic`, and deletion re-parses the result before replacing
+the file.
+
 ## Adding a bank parser
 
 Implement `parser.Parser` and call `parser.Register` from an `init`. Nothing