ci: восстанавливать потерянные запросы ревью (#555)

Issue: #555
User-Visible: no

PROCESS.md

@@ -1069,6 +1069,25 @@ npm ci, Python и Chromium, оставаясь исполненной job: до
 Если метка не сменилась, значит упал сам прогон, а не работа: смотреть логи и
 сообщать владельцу, а не продолжать опрос.
 
+**Очередь S4/S7 сверяется отдельным bounded controller (#555).** Workflow
+`process-reconcile.yml` раз в полчаса делает один снимок открытых задач и
+завершается — активного polling одинакового состояния и вызова модели на каждый
+тик нет. Он сопоставляет последнюю постановку `S4`/`S7` с run по номеру задачи и
+этапу; если стадия успела подготовить материал, дополнительно проверяет
+запечатанные run/attempt, SHA/tree, список блобов ТЗ и номер раунда. Текущий
+`blocked`, `review-4` или снятая review-метка всегда сильнее старого события.
+
+Автоматически и не более одного раза повторно применяется только сама review-метка после доказанно
+потерянного события либо transient-исхода до получения запечатанного результата
+(`cancelled`, `timed_out`, `stale`, `startup_failure`, `skipped`). Это не применяет
+вердикт и не расходует цикл: обычный конвейер заново читает актуальные labels и
+материал. Здоровый running run не трогается. Failure guard, неизвестная связь,
+чужой material/stage/attempt, success без смены метки и сбой после появления
+`review-result`, а также потеря повторного события получают один дедуплицированный диагностический комментарий и
+эскалацию человеку — второй вызов модели или S8 по догадке запрещены. Перед любой
+записью controller перечитывает состояние; итог каждого прохода публикуется как
+`houseplan-process-reconcile/v1` artifact.
+
 **Конвейер — идемпотентный контроллер, а событие лишь будит его** (#499). Guard
 читает метки issue текущими, а не из снимка события: прогон мог простоять в очереди,
 пока владелец снял метку — отозванный запрос не исполняется, и комментария об этом