fix(rules): stop a rule with a spaced name from vanishing on save

A rule named "justeat orders" in the field labelled Name was written to
rules.json correctly and then dropped by every reader, because load()
required ^[a-z0-9][a-z0-9-]*$ and the save path validated nothing. The
rule stayed in the file, invisible in the dialog, never applied by the
post-new hook, and the next save from the dialog would have deleted it
outright.

The asymmetry was the defect, not the pattern. TagRules::validate() is
now the single predicate: the dialog refuses to save against it, and
load() uses it to repair rather than drop, so a rule that fails is
visible and fixable instead of silently discarded.

- The typed name is sanitised into an id when the field is committed,
  so the field shows what will reach the file. uniqueId() suffixes a
  collision, since sanitising is many-to-one and can manufacture the
  duplicate that load() then drops.
- An already-legal id is never rewritten, including one like "a---b"
  that sanitising would otherwise collapse. Rewriting valid ids would
  churn a file mailctl also reads.
- A bad id loads repaired, with the warning kept: what is on disk is
  not what the hook runs until the file is saved back.

Deliberately not mirrored into mailrules.py. The hook tags real mail
unattended every ten minutes, where silently renaming an id is worse
than dropping the rule; the file converges as soon as the dialog saves.
No format change, so no version bump and no two-repo commitment.

The load warning was not missing: it had been showing "1 rule could not
be read and was skipped" on every open, in the same font and colour as
the intro prose two lines above it, and read as more explanation. It is
now a red banner beside Save, with an icon and a dismiss button, and it
says the rules need attention rather than that they were skipped, which
is no longer true. Dismissal is per-appearance only; a persistent one
would re-hide the problem that went unnoticed for a session.

Both new dialog tests were confirmed to fail with the sanitiser
reverted, and the banner's styling, position and dismissal each fail
under mutation. 20 of 20 suites green, 34 tests in test_tagrules.

Closes item 83.

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

1 files changed, 13 insertions, 0 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 10eb843..b66c3b2 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -254,6 +254,19 @@ a failure or a `-1` count fails against correct code. This was recorded in
 building the rules. Assert on the positional contract, never on a provoked
 failure.
 
+**A writer that does not validate what its reader requires loses data
+silently.** `TagRules::save()` wrote any id and `load()` required
+`^[a-z0-9][a-z0-9-]*$`, so a rule named `justeat orders` in a field labelled
+**Name** was written correctly, dropped on every read, invisible in the dialog,
+still occupying the file, and never applied by the hook. The next save from the
+dialog would have deleted it outright. `TagRules::validate()` is now the single
+predicate both sides use; a bad id loads REPAIRED rather than dropped, so the
+rule can be seen and fixed. Two lessons beyond the fix. The load warning already
+existed and was correct and useless, because the rule it named could not be
+reached, and a warning the user cannot act on teaches them to ignore warnings.
+And the repair belongs in the editor, not in `mailrules.py`: the hook tags real
+mail unattended, where a silent rename is worse than a drop.
+
 **Rule counts must count MESSAGES.** `requestCounts` counts threads, which is
 right for the placeholder pane because a click there produces thread rows. A
 rule tags messages, so a thread count understates every rule matching part of a