feat(rules): move a rule between global and project scope, keeping its id, history, areas and edges (#4063)

A rule's home is its reach: a rulebook topic makes it global, a project makes it
that project's. There was no way to change one, so a project rule decided to be
global could only be recreated and the original trashed — losing the id every
record cites, its edit history, its area tags and its relations.

- services.rulebooks.move_rule(rule_id, user_id, topic_id= | project_id=):
  exactly one destination (the model's CHECK), owned by the caller, not the
  rule's current home. A topic already holding a live rule with the same title
  is refused with a message naming that rule, instead of uq_rule_per_topic
  failing the commit. Someone else's rule reads as not found.
- Deliberately NOT done, and said in the docstring: no version (a version is
  what a rule said, milestone 323 decision 4), no duplicate gate (nothing new
  enters the corpus), no re-embed (retrieval reads the home at query time).
- Both doors: MCP move_rule, REST POST /api/rules/<id>/move (rule 33).
- UI: RuleHomePicker, one component in the rule editor (a global rule) and a
  project's rules tab (a project rule), so the two cannot drift on what a
  destination is.
- using-scribe names move_rule under "Where a new rule goes". Plugin
  2026.09.15.1626.

Milestone 414 step 3.

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

src/scribe/mcp/tools/rulebooks.py

@@ -862,6 +862,38 @@ async def rule_history(rule_id: int, version_id: int = 0) -> dict:
     }
 
 
+async def move_rule(rule_id: int, topic_id: int = 0, project_id: int = 0) -> dict:
+    """Move a rule to a new home, keeping its id, history, areas and edges.
+
+    A rule's home IS its reach. In a rulebook topic it is GLOBAL: it applies in
+    every project and reaches any session whose work matches it. On a project
+    it applies to that project only. So this is how a project rule that turns
+    out to hold everywhere becomes global (pass `topic_id`), and how a global
+    rule that only one project needs becomes that project's (pass
+    `project_id`). Name exactly one.
+
+    Reach for this INSTEAD of recreating the rule in the other home and
+    deleting the original: that loses the id every record cites it by, its
+    edit history, its area tags and its relations.
+
+    A move is a decision about where a rule binds, so propose it and move on a
+    yes, the way create_rule proposes a new rule — and record why where the
+    decision lives (a task or note). The rule's history does not record a
+    move: it holds what the rule SAID, and a move changes none of that.
+
+    Refused with a message when: neither or both destinations are named, the
+    destination is not yours, the rule is already there, or the topic already
+    has a rule with this title (rename one first).
+    """
+    uid = current_user_id()
+    rule = await rulebooks_svc.move_rule(
+        rule_id, uid, topic_id=topic_id, project_id=project_id,
+    )
+    if rule is None:
+        raise ValueError(f"rule {rule_id} not found")
+    return await rulebooks_svc.rule_detail(uid, rule)
+
+
 async def delete_rule(rule_id: int, confirmed: bool = False) -> dict:
     """Move a rule to the trash (recoverable). Requires confirmed=True."""
     uid = current_user_id()
@@ -1019,7 +1051,7 @@ def register(mcp) -> None:
         list_rulebooks, get_rulebook, create_rulebook, update_rulebook, delete_rulebook,
         list_topics, create_topic, update_topic, delete_topic,
         list_rules, get_rule,
-        create_rule, create_project_rule, update_rule, delete_rule,
+        create_rule, create_project_rule, update_rule, move_rule, delete_rule,
         create_preference, update_preference,
         relate_rules, unrelate_rules,
         rules_due_for_verification, mark_rule_verified,