docs: state the invariant the pipeline was missing

A review run always moves the label. The rule is written down because its absence
cost a real stall: a green code review whose merge conflicted left the label alone,
the waiting author polled thirty times and reported the limit as exhausted, and a
verdict that existed reached nobody.

Both documents now say what S6-in-progress means when the verdict was green and
only the merge failed — rebase, not rework, and the verdict still stands. They also
say that a label which did not change means the run failed rather than the work, so
the answer is logs and the owner, not more polling. Cycles are counted per stage.

Issue: #114
User-Visible: no

PROCESS.md

@@ -618,6 +618,25 @@ Medium-находку, кладёт документ в `docs/reviews/` ветк
 секунд, не более 30 попыток. Смотреть на метку, а не на комментарий: метка и есть
 состояние. При `blocked` не ждать — задача ждёт владельца.
 
+**После прогона ревью метка меняется всегда.** Инвариант появился не сразу: первая
+редакция при конфликте слияния оставляла метку на месте, и это оказалось тупиком —
+автор ждёт смену метки, метка не менялась, и он тридцать раз опрашивал впустую,
+чтобы отчитаться «лимит исчерпан» при зелёном вердикте. Состояние, из которого
+никто не может выйти и о котором никто не узнает, для конвейера хуже громкой
+ошибки.
+
+Поэтому зелёное код-ревью с неудавшимся слиянием ведёт не в `S8-merged`, а в
+`S6-in-progress`: работа действительно вернулась к автору, только осталась не
+правка кода, а ребейз. Вердикт при этом в силе, переделывать нечего. После ребейза
+метка `S7-code-review` возвращается и ревью идёт заново — не формальность:
+после ребейза на ушедший вперёд `dev` это другой код.
+
+Если метка не сменилась, значит упал сам прогон, а не работа: смотреть логи и
+сообщать владельцу, а не продолжать опрос.
+
+Цикл считается **по этапу**: вердикт по ТЗ не расходует бюджет код-ревью. Раньше
+считались все вердикты подряд, и первое код-ревью #89 получило `r2/4`.
+
 ---
 
 ## 11. Исключения