fix(process): free the reviewer prompt budget, rules stay in REVIEWER.md (#750)

The code-review prompt sat at exactly 1 400 of its 1 400 words (#634), so
any new line turned the budget test red, and #707/#726 already had to route
their notes through job outputs. Part of the text was dead or a retelling
of the reviewer digest, which #634 says the prompt must not repeat:

- the mutants fragment of the track line: since #709 `mutants` is always
  false, so «прогнаны Validate» was unreachable;
- «Отсутствие мутантов по диффу — не находка» in the show line: a rule of
  every track, already in REVIEWER.md «Трек show» and §10.4;
- three retellings — the repeated round, the gate scope and the severity
  paragraph — now one-line references to the REVIEWER.md sections. The ban
  on a separate issue for an in-scope Medium stays in the prompt: the model
  files issues itself, and that mistake is expensive.

What only the prompt said moves into REVIEWER.md with links to the canon:
the spec delta is the diff of the issue body, a doubt about locality means
a full review with a stated reason, the three smoke-select answers
(docs/TESTING.md), and geometry without invariants in the report is an
unrun gate.

The prompt is now 1 130 words; the 1 400 threshold stays, the difference
is headroom. A new test ties every «docs/process/REVIEWER.md, «X»»
reference in the prompt to an existing `## X` section.

Issue: #750
User-Visible: no
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd

.github/workflows/_process.yml

@@ -1170,9 +1170,9 @@ jobs:
               ничего не вернул на правки и цикла не образует (#227).
               Номер захода нужен для имени документа — два документа с
               одинаковым номером затёрли бы друг друга.
-            Трек: ${{ needs.prepare.outputs.track || 'ask' }} (PROCESS.md §5) · мутанты по диффу на материале: ${{ needs.prepare.outputs.mutants == 'false' && 'не запрашивались' || 'прогнаны Validate' }}
+            Трек: ${{ needs.prepare.outputs.track || 'ask' }} (PROCESS.md §5)
 
-            ${{ needs.prepare.outputs.track == 'show' && needs.guard.outputs.stage == 'code' && 'Трек show: объём и серьёзность находок — docs/process/REVIEWER.md, «Трек show» (#696). Отсутствие мутантов по диффу — не находка.' || '' }}
+            ${{ needs.prepare.outputs.track == 'show' && needs.guard.outputs.stage == 'code' && 'Трек show: объём и серьёзность находок — docs/process/REVIEWER.md, «Трек show» (#696).' || '' }}
 
             ${{ needs.prepare.outputs.rebase_note }}
 
@@ -1212,17 +1212,8 @@ jobs:
                  FILTERING.md, STAIRS.md, RADAR.md, PDF-EXPORT.md,
                  STYLING-HOOKS.md.
 
-            **Если цикл не первый — объём разбора по дельте, а не заново**
-            (PROCESS.md §2.10, issue #214): найди вердикт и материал
-            предыдущего раунда (блок «Материал раунда» его документа), объяви
-            дельту `git diff <тот SHA>..HEAD` (для spec — дифф тела issue или
-            файла ТЗ), по каждой находке покажи, чем именно она закрыта —
-            строка кода или текста, а не заявление автора, — и заново проверяй
-            только AC, чьё доказательство дельта задевает. Разбор остаётся
-            ПОЛНЫМ, если дельта не локальна: ребейз на ушедший вперёд dev,
-            смена контракта, новая подсистема, объём сопоставим с задачей.
-            Сомневаешься — разбирай полностью и скажи почему. Сокращается
-            объём РАЗБОРА, а не строгость.
+            Цикл не первый — разбор по дельте (PROCESS.md §2.10):
+            docs/process/REVIEWER.md, «Повторный раунд».
 
             Для этапа spec: ТЗ живёт в теле issue (#517) — читай его, а не файл.
             Файлы docs/specs/<NN>-*.md — архив ТЗ до 2026-09-10: если такой файл
@@ -1265,22 +1256,8 @@ jobs:
             `npm run build` со сверкой трёх копий бандла. Свежесть скриншотов
             документации — не гейт задачи (#697): её обновляет бот на dev.
             ${{ needs.guard.outputs.stage == 'spec' && 'Зависимости и Chromium на этапе spec не ставились (#696).' || (needs.prepare.outputs.track == 'show' && 'Зависимости установлены (`npm ci` не нужен); Chromium — только если тело issue называет смоук (#696).' || 'Зависимости уже установлены workflow, Chromium тоже — `npm ci` выполнять не нужно.') }}
-            По диффу и AC: браузерные смоки — названные в AC
-            плюс вывод `node scripts/smoke-select.mjs --base <base> --head <head>`,
-            приложенный к комментарию с решением по каждой строке: прогнал либо
-            не прогнал и почему. Три вида ответа инструмента разные: «прямое
-            совпадение», «зарегистрированная связь», «НЕОПРЕДЕЛЁННОСТЬ» — связь
-            не доказана, и это не разрешение ничего не прогонять; слабые связи —
-            повод посмотреть, а не обязанность прогонять;
-            `npm run golden:verify` при метке `ci:golden`;
-            `python -m pytest tests_backend -q` при правке
-            `custom_components/**/*.py`; инварианты модели
-            `npm run invariants -- --config <экспорт>` при правке геометрии или
-            ссылок на неё (#254) — задача меняет геометрию, а инварианты в
-            отчёте не названы, это непрогнанный гейт, а не мелочь;
-            performance-профили, если названы в AC. Дисциплина «тест должен
-            уметь падать» не отменяется, но применяется к тем тестам, которые
-            ты прогонял.
+            По диффу и AC — смоки, golden, pytest, инварианты, performance:
+            docs/process/REVIEWER.md, «Объём гейтов».
 
             **В комментарии обязателен перечень: какие гейты прогнал, какие нет и
             почему.** Раздел «чего не проверял» в документе ревью — не
@@ -1288,13 +1265,9 @@ jobs:
 
             Ты НЕ правишь ни ТЗ, ни продуктовый код. Только оцениваешь.
 
-            Серьёзность: High блокирует; Medium В СКОУПЕ задачи чинится в ней
-            же — без High это жёлтый вердикт и возврат автору, отдельный issue
-            НЕ заводится (#202); Low либо правится, либо снимается с записью.
-            Жёлтый вердикт допустим и при полностью выполненных AC, если
-            изменение не решает заявленный сценарий или ухудшает смежный.
-            Продуктовое рассуждение расширяет вопросы, но не отменяет AC и не
-            даёт права менять скоуп.
+            Серьёзность и вердикт — docs/process/REVIEWER.md, «Находки и вердикт»:
+            Medium В СКОУПЕ — жёлтый вердикт и возврат автору, отдельный issue
+            НЕ заводится (#202).
 
             Только Medium-находку ВНЕ скоупа задачи (попутный дефект соседнего
             поведения, который в этой ветке чинить нельзя) заведи отдельным