fix(plugin): the instruction surfaces still said every rule binds (#3849)

Step 3 shipped a line a session can receive — "Preference that may apply
here …" — into surfaces that told it, in the most authoritative voice it
has, that anything arriving in that shape is binding. That is the confusion
milestone 399 exists to prevent, arriving through the one channel a session
has least reason to doubt.

Silent in both directions, which is why it could not wait for step 6. A
session treating a preference as a rule refuses to proceed over something
the operator merely preferred; and it loses the whole reason preferences
exist, which is that they are brought up to date rather than obeyed.

Three surfaces, each to its own budget:

- SKILL.md gets the full account: kind decides force, the injected line names
  which in its opening words, and a preference is the one record a session
  keeps current itself (update_preference, with what taught the change).
- scribe_static_context.md gets six lines — enough to tell the kinds apart
  and to say a preference is yours to update.
- _INSTRUCTIONS gets four words. It is a MAP at 1978 of its 2000-char budget
  (#2562), and the detail belongs in the surfaces above and in the tool
  docstrings, which is what that budget exists to force.

Guarded so it cannot drift back: a surface that claims rules bind must name
the kind that does not. Pinned on the CLAIM rather than the word "bind",
because a bare substring also matches bind_repo, list_repo_bindings and
server.py's DNS-rebinding comment — a guard that would one day fail a skill
about repo binding is rule 167's named failure, raising a false alarm about
the very thing it protects. Falsified against all three surfaces losing the
mention.

Plugin version minted: the cache refreshes only on a version bump (#2209),
so a skill edit without one reaches no installed plugin.

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

plugin/skills/using-scribe/SKILL.md

@@ -58,9 +58,27 @@ Two constraints on *how* that's achieved:
 
 2. **Standing rules are binding — and the ones you were handed are not all of
    them.** Load the resident set via `list_always_on_rules()` at session start
-   (see "Do this first"); treat every one as binding. Pull a rule's full
-   statement with `get_rule(id)` when it's about to bite. When a project is in
-   scope, `enter_project(id)` also returns its applicable rules.
+   (see "Do this first"). Pull a record's full statement with `get_rule(id)`
+   when it's about to bite. When a project is in scope, `enter_project(id)`
+   also returns its applicable rules.
+
+   **`kind` says how much force a record carries, and it is never something to
+   infer.** A **rule** must be followed: ignoring it breaks something or
+   crosses a boundary. A **preference** records how the operator wants work
+   done, and ignoring it costs consistency rather than correctness. Both are
+   worth following and both arrive the same way; only one is a mistake to
+   miss. An injected line names which in its opening words — *"Standing rule
+   that may apply…"* against *"Preference that may apply…"* — and every
+   payload carries `kind` outright.
+
+   **A preference is the one record you keep current yourself.** When the
+   operator corrects you, or the preference on file no longer matches how they
+   actually want something done, `update_preference` — that is expected, not a
+   liberty, and it wants the task or note that taught the change. Say in the
+   same turn that you did it, so they can disagree while it is in front of
+   them. A rule waits for the operator instead: `create_rule` proposes and
+   asks. If what you learned is that something MUST be done a certain way,
+   that is a rule to propose, not a preference to harden in place.
 
    Rules come in two tiers. **Always-on** rules are delivered — they arrive
    whether or not you ask. **Conditional** rules are RETRIEVED, and one binds