ci(process): раунд ревью ждёт Validate событием, а не сном раннера (#636)

Стадия prepare спала ≈ 28 минут на раунд, пока шёл Validate с мутантами на
материале (модель работает 10–12); за неделю ≈ 420–500 job-минут простоя и
потолок бюджета стадии 55 минут.

- validate-gate.mjs: `--no-wait` — гейт диспатчит прогон, убеждается, что тот
  встал на материал (#539 сохранён), и возвращает `pending` (код 2) вместо
  ожидания; завершённый зелёный/красный отдаёт сразу, как прежде.
- process.yml prepare: третий исход `proceed=pending`: запечатанный маркер
  `review-pending-<issue>-<run>-<attempt>` (issue, stage, branch, material_sha,
  validate run) и выход; модель и интеграция не запускаются; возврат автору —
  только на явном `false`.
- process-resume.yml + scripts/process-resume.mjs: на `workflow_run: completed`
  Validate по ветке issue/* — если метка S7 стоит, активного прогона нет и
  последний прогон оставил маркер на этот SHA, переставить S7 (HP_PROCESS_TOKEN);
  новый прогон находит завершённый dispatch сразу. Без маркера не будит.
- process-reconcile.mjs: читает маркер и состояние Validate на материале;
  идёт — wait, завершился/пропал без продолжения — retry; без маркера — прежний
  escalate. Общий loadSealedArtifact, экспорт processRuns/artifactNames.
- preflight сверяет process-resume.yml между main и dev наравне с process.yml.
- Тесты: validate-gate (4), process-resume (8, включая контракт трёх workflow),
  process-reconcile (2); мутанты gate-no-wait-still-sleeps,
  resume-wakes-round-without-marker, resume-ignores-active-run,
  reconcile-wakes-pending-while-validate-active. PROCESS.md §10.4, AGENTS.md.

Issue: #636
User-Visible: no

PROCESS.md

@@ -959,7 +959,14 @@ Medium-находки вне скоупа задачи (#202), кладёт до
 
 **Ревью не начинается на красном коде** (#510). После фиксации материала конвейер
 запускает Validate с мутантами по диффу на этом SHA (`scripts/validate-gate.mjs`:
-`workflow_dispatch validate.yml -f mutants=true`) и ждёт его до 45 минут. Красный или
+`workflow_dispatch validate.yml -f mutants=true`). **Ждёт его не раннер, а событие**
+(#636): подготовка убеждается, что dispatch встал на материал, кладёт запечатанный
+маркер ожидания `review-pending-…` и завершается; по завершении Validate
+`process-resume.yml` (`workflow_run`) переставляет метку `S7-code-review`, и новый
+прогон конвейера находит завершённый dispatch сразу. Страховка на потерянное
+событие — `process-reconcile.yml`: успешный прогон подготовки с маркером и уже
+завершённым Validate он будит повторной меткой, без маркера — как прежде, только
+диагностика. Будить без маркера нельзя: это второй вызов модели. Красный или
 пропавший прогон возвращает задачу в `S6-in-progress` с комментарием и ссылкой —
 код никто не читал, цикл ревью не израсходован. Мутанты по диффу вообще бегут
 только по явному запросу: на кандидате ревью, кандидате слияния (#492) — оба
@@ -976,8 +983,9 @@ Medium-находки вне скоупа задачи (#202), кладёт до
 
 Ожидание gates, работа модели и публикация/интеграция — три независимых jobs
 (#551) с отдельными бюджетами 55, 45 и 55 минут. Поэтому долгий Validate не
-съедает время модели, а ожидание кандидата после зелёного вердикта не обрывает
-готовый review. Между jobs передаётся запечатанный artifact: run/attempt, issue,
+съедает время модели (с #636 — и не занимает раннер: до этого подготовка спала
+≈ 28 минут на раунд при 10–12 минутах работы модели), а ожидание кандидата после
+зелёного вердикта не обрывает готовый review. Между jobs передаётся запечатанный artifact: run/attempt, issue,
 этап, раунд, branch, SHA/tree материала, якоря ТЗ и результат Validate. Получатель
 сверяет полный набор файлов, SHA-256 и все поля с outputs предыдущей стадии;
 неполный, чужой или устаревший результат fail-closed не публикуется и не разрешает