docs(mcp): encode rule-scope model in rulebook tool descriptions

Make the always-on / subscribed / project-rule distinction explicit at the
authoring surface so it can't silently regress (for this operator or other
users). Previously the tools said only 'cross-project rulebook rule' and a
bare 'subscribe a project' — nothing steered project-specific detail away
from shared rulebooks, which is how a Scribe-pinned rule ends up binding
every family project.

Principle encoded in 5 places: a rule's home is chosen by WHO it should bind,
and both rulebook tiers are SHARED so their rules stay general — they differ
in reach (all projects vs opt-in by theme), not generality. Project-specific
detail goes in create_project_rule.

- server.py MCP instructions: add the 3-tier authoring principle
- create_rule / create_rulebook / create_project_rule / subscribe_* docstrings
- using-scribe SKILL.md: a 'Where a new rule goes' note for the pull path

Refs #755

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/scribe/mcp/server.py

@@ -82,8 +82,24 @@ new engineering rules to CLAUDE.md or to ~/.claude/.../memory/feedback_*.md
 — those stores are reserved for facts about the user (preferences, role,
 communication style) and codebase onboarding pointers, respectively. Before
 creating a rule, call list_always_on_rules and list_rules(project_id=...) to
-avoid duplicates. Coordinate with the operator on whether a new rule belongs
-in a project, an existing rulebook+topic, or a new rulebook.
+avoid duplicates.
+
+Choose a rule's home by WHO it should bind, and keep each home's rules at the
+right altitude:
+  - Always-on rulebook (a rulebook flagged always_on) — universal norms that
+    bind EVERY one of your projects. Reserve for cross-project standards.
+  - Subscribed rulebook (always_on off; projects opt in via
+    subscribe_project_to_rulebook) — a reusable, THEMED module of general
+    rules that binds only the projects which subscribe. Its rules must make
+    sense for every project that could subscribe, never one specific project
+    (e.g. a design-system rulebook: design-specific but project-agnostic — no
+    rule names a single app).
+  - Project rule (create_project_rule) — anything specific to ONE project.
+Both rulebook tiers are SHARED, so their rules stay general; the difference
+between them is REACH (all projects vs opt-in by theme), not generality. Rule
+of thumb: names a specific project's files/paths/quirks -> project rule; a
+standard a CATEGORY of projects shares -> subscribed rulebook; a universal
+norm -> always-on rulebook. Coordinate with the operator on which home fits.
 
 That boundary cuts the other way too. Because rules are pull-only, a fresh
 session won't reach for them unless its always-loaded context says to. So