docs(review): stop rule in the plan loop, review loop and critic prompts (decision 217, 220)

/trekplan Phase 9: when --record or the gate reports the stop rule there
is no new round; AskUserQuestion with the class and counts, "Known issue"
(--accept-open, a security finding refused) or "New mechanism" (stop, the
plan stays unapproved); the round-3 blocker path never offers
--extra-round after the stop rule. Phase 10 prints round of
max_rounds + extra_rounds.

/trekexecute Phase 7.2 step 4: after a round-2 BLOCK or fixed-pending,
before any R-step, review-rounds.mjs prepare --dry-run; review-stop-rule:
gives the same question ("Known issue" = /trekreview --answers, a BLOCKER
keeps the merge locked; "New mechanism" = stop). /trekreview Phase 3 tells
the stop rule's exit 1 from the cap's. plan-critic and scope-guardian:
rule_key names the class, never the instance.

New pins in review-loop-docs, critic-severity-rules and review-prose-pins.

Part 1, step 1.4 of the E plan.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

agents/scope-guardian.md

@@ -182,6 +182,11 @@ this block inline *is* the hand-off; do not attempt to write a file.
 One object per scope-creep / gap / dependency finding. `file`/`line` point at the
 plan step (or the brief requirement) the finding concerns; `rule_key` is a short,
 stable id for the finding class (used for exact-match dedup against plan-critic).
+`rule_key` names the class, never the instance: a catalogue key when one fits,
+else the kind (`creep`, `gap`, `dependency`, or `<kind>/<short-id>`), the same
+kind for every finding of that kind. The plan gate's stop rule counts findings
+by class (the catalogue key, else the part before the first `/`), so a key
+made for one instance hides a class that keeps coming back.
 Emit `"findings": []` when the plan is fully aligned.
 `previous` (from round 2; omit it in round 1) holds one `{id, resolved}` per
 finding the current `## Critic Verdict` lists; `resolved` is `true` or