feat(instructions): a rule proposal has five answers, and three of them route (#3733, #3896)

Step 6 of both milestone 385 (lessons) and 399 (preferences). #3896 asked for
the fourth and fifth answers in one pass, because two people each adding one
branch to a three-way distinction produce a list that does not read as a set.

create_rule now opens by asking what kind of thing is being held, with one
question that sorts it — what happens if someone doesn't do this? Something
breaks, a boundary is crossed: a rule. It gets done a way the operator didn't
want: a preference. They lose time rediscovering it: a lesson. The closing
question grew the two matching answers, and they are named as first-class
outcomes rather than places a proposal lands when it fails. An observation
that turns out to be a lesson has been routed, not dropped.

Stated as a practice, not a prohibition (rule 165). #3557's first cut opened
"NOT YOURS TO CALL UNPROMPTED" and cost the noticing; the wanted behaviour
here is still more proposals, and what changes is only which door they go
through.

create_note says the same from its side, so routing does not depend on having
opened create_rule first — and its existing rule test ("a mistake, not merely
uninformed") turned out to name the lesson exactly. create_lesson names the
fifth kind so the set is complete from every door. create_project_rule's
citation of the loop names five answers, since it cites rather than repeats.

The force axis has one owner (decision #4027): using-scribe states all three
strengths, the sorting question, that updating a preference mid-work is the
normal case, and that preferences shape how work is done and never what gets
recorded. _INSTRUCTIONS carries the pointer — "Rules bind; preferences guide
and you keep them current; lessons inform." It had 14 characters of headroom,
so the clause is paid for by trimming atmosphere from three other lines; 1998
of 2000 now.

Guards: the proposal-loop test learns the preference branch, the lesson
branch and the force question, on both rule surfaces; guidance-ownership gains
the force-axis topic (shared with the docstrings, for the moment a proposal is
actually written) and the preference-scope topic; a new guard pins that the
index names all three strengths and who keeps the middle one current, with its
can-fail case being the omission that actually happens — a kind added to the
product while the index still describes the corpus that came before it.

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

src/scribe/mcp/tools/notes.py

@@ -120,6 +120,15 @@ async def create_note(
       is a task nobody will ever see again.
     - future sessions must OBEY it -> create_rule. The test is whether
       ignoring it would be a mistake, not merely uninformed.
+    - it is how the operator wants work DONE, and ignoring it costs
+      consistency rather than correctness -> create_preference. No approval
+      loop, and it stays yours to keep current as they correct you.
+    - "merely uninformed" is the other half of the rule test, and it has its
+      own home: something you learned that a later session should meet at the
+      moment it applies -> create_lesson. A note is found by topic when
+      someone goes looking; a lesson arrives on its own, keyed to the
+      SITUATION. If you would want this handed to you next time you were in
+      that spot, it is a lesson.
     - reusable code with a place in a repo -> create_snippet. The location is
       what lets it be found from the file someone is about to edit.
     - a procedure followed start to finish -> create_process.