feat(rules): retrieval honours a rule's home — global everywhere, a project's rules only in that project (#4074)

semantic_search_rules searched every rule the user owned, and every hook arm
called it without a project, so each project's rules were injected into every
other project's sessions and a project rule meant nothing a session could feel.

The search now takes a scope: global rules by default (an unbound session, or a
caller that forgets to say), global plus project N when given project_id (N's
rules only if the caller can read that project, through access.can_read_project),
and every owned rule with everywhere=True. The four hook arms and the report
preference lookup pass the session's project; an explicit
search(content_type="rule") scopes to its project_id, or asks the whole rulebook
without one.

Milestone 414 step 1. Guarded by an AST walk that every hook call site passes
project_id, and an integration test on real Postgres that a rule is reached only
from its home.

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

src/scribe/mcp/tools/search.py

@@ -18,7 +18,7 @@ from scribe.services import rulebooks as rulebooks_svc
 from scribe.services.retrieval_telemetry import record_retrieval, retrieval_summary
 
 
-async def _search_rules(uid: int, q: str, limit: int) -> dict:
+async def _search_rules(uid: int, q: str, limit: int, project_id: int) -> dict:
     """Rules by meaning — a separate result shape because a rule IS different.
 
     A rule hit carries `why` and `how_to_apply`: they are the operational half
@@ -29,10 +29,17 @@ async def _search_rules(uid: int, q: str, limit: int) -> dict:
     the moment someone is about to act on a rule, and "this asserts a fact
     nobody has confirmed" is part of what the rule says.
 
-    Rules are not project-scoped the way notes are (a family rule belongs to no
-    project), so `project_id` and `system_id` do not apply here.
+    `project_id` scopes the way it does for notes, with one difference: a
+    GLOBAL rule (one in a rulebook) belongs to no project and applies in every
+    one, so a scoped search returns global rules plus that project's own.
+    Without a project it asks the whole rulebook — every rule, whatever its
+    home — because that is the question an unscoped "is there a rule about
+    this" is asking. `system_id` does not apply to rules.
     """
-    raw = await semantic_search_rules(uid, q, limit=limit)
+    if project_id:
+        raw = await semantic_search_rules(uid, q, limit=limit, project_id=project_id)
+    else:
+        raw = await semantic_search_rules(uid, q, limit=limit, everywhere=True)
     return {
         "results": [
             {
@@ -84,7 +91,9 @@ async def search(
             Reach for 'rule' when you want to know whether a standing
             instruction covers something: "is there a rule about release
             tagging?". A hit carries the rule's `why` and `how_to_apply`,
-            which the session-start payload does not.
+            which the session-start payload does not. With a project_id,
+            rules come back as the global rules plus that project's own;
+            with 0, every rule in the rulebook.
         limit: maximum number of results (1-50).
         project_id: Scope results to one project. PASS THE ACTIVE PROJECT'S ID
             whenever a project is in scope (the one you entered with
@@ -108,7 +117,7 @@ async def search(
     uid = current_user_id()
     limit = max(1, min(limit, 50))
     if content_type == "rule":
-        return await _search_rules(uid, q, limit)
+        return await _search_rules(uid, q, limit, project_id)
     is_task = {"note": False, "task": True}.get(content_type)  # None => any
     t0 = time.perf_counter()
     report: dict = {}