fix(rules): the registration guard counts 24 now that rule_outcome exists

Milestone 419's own subject, committed while building it. The module header
of mcp/tools/rulebooks.py says the tool count "lives in the registration
test, which fails when it drifts" — I read that line while adding the tool
and did not act on it, which is a rule surfaced, read, and silently
unchanged. The only reason it was caught is that the guard exists and CI ran
it; nothing about my process would have found it.

Worth stating plainly because the milestone is about exactly this class of
miss, and step 1 shipped the record that would let a future session SEE it:
a rule read and not followed is invisible unless something independent
notices. Here the something was a test written by whoever last changed this
count.

Integration was already green on the previous run, so the migration, the
backup round trip and the new `detail` column were never in question — this
was one integer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy

tests/test_mcp_tool_rulebooks.py

@@ -206,8 +206,10 @@ def test_register_attaches_every_tool():
     # always-on exclusion tools with the tier they served.
     # 22 since milestone 414 retired subscriptions and suppressions: the two
     # subscribe tools and the four suppress/unsuppress tools. 23 with move_rule
-    # (milestone 414 step 3), the way a rule changes home.
-    assert len(mcp.names) == 23
+    # (milestone 414 step 3), the way a rule changes home. 24 with
+    # rule_outcome (milestone 419 step 1), the way a rule says what it
+    # actually changed.
+    assert len(mcp.names) == 24
     # spot-check a few names
     assert "list_rulebooks" in mcp.names
     assert "create_rule" in mcp.names