fix(process): integrate runs every pipeline script from one dev snapshot (#749)

The body of _process.yml is read from dev (@dev, #623), so the flags and
formats it passes to scripts are dev's. After "Опубликовать документ ревью"
the working copy of job integrate is the task branch, and a show/ship branch
with a clean merge is not rebased before review: its scripts/ may lag dev by
days. review-doc-guard.mjs silently ignores unknown flags (the anchor lost
#726 route and #737 usage), and a stale merge-candidate.mjs merges the old
way. Only two calls (#723 push refusal, #726 route) were taken from dev, each
with its own extraction, and on ship/reuse the remaining ones ran dev's
version anyway: the script version depended on the path.

Now one step right after setup-node extracts
`git archive origin/dev scripts .github/workflows/validate.yml` into
$RUNNER_TEMP/dev-tools and every repo script of the job runs from there via
TOOLS (review-result-gate, review-doc-guard, reviews-index, merge-candidate,
process-track route, status-label). validate.yml is part of the snapshot
because workflow-jobs.mjs reads it relative to itself; without it ci-proof
answers `failed (#622)` and every code merge would return to S6. The working
copy stays the material: git, the document and paths are judged there.

PROCESS.md §10.4 gets the paragraph "Скрипты конвейера — из dev": the
model_review exception, merges of pipeline changes judged by dev's version,
and compatible edits of the Validate proof contract.

Tests: test/process-integrate-tools.test.mjs is the job contract (no step
calls scripts/ from the working copy, every call goes through the snapshot,
one archive from origin/dev with validate.yml, and the step as is yields a
directory where ci-proof resolves the job contract); publish-push-refusal
runs the publish step and the #413 step on real bash with a task branch whose
review-doc-guard.mjs exits 7 (red with the old call). Existing harnesses take
the snapshot step before the publish and decide steps; the #706 mutant anchor
follows the status-label call.

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

PROCESS.md

@@ -1317,6 +1317,28 @@ Matysh/houseplan-card/.github/workflows/_<имя>.yml@dev` с `secrets: inherit`
 Validate запускает `ship-review.yml` dispatch'ем с `-f tag=nightly` (§11.7,
 #727): входы и права для этого в `main` уже есть, тонкие файлы не меняются.
 
+**Скрипты конвейера — из `dev`** (#749). Тело читается из `dev`, поэтому и
+скрипты, которые оно зовёт со своими флагами и форматами, — версии `dev`. Job
+`integrate` сразу после `setup-node` снимает один снимок `git archive
+origin/dev scripts .github/workflows/validate.yml` и зовёт из него каждый
+repo-скрипт: `review-result-gate`, `review-doc-guard`, `reviews-index`,
+`merge-candidate`, `process-track route`, `status-label`. Снимок один на job —
+одна версия на весь заход, а не смесь по шагам. Так же уже работают шаг трека
+(#707), страж ребейза (#698) и разбор отказа push (#723). Рабочая копия ветки
+задачи — только материал: git-команды, документ и пути судятся в ней. Ветка
+`show`/`ship` с чистым слиянием до ревью не ребейзится и может нести
+`scripts/`, отставшие от `dev` на дни: её `review-doc-guard.mjs` молча
+проглотил бы неизвестный флаг, её `merge-candidate.mjs` слил бы по-старому.
+`validate.yml` в снимке обязателен: `workflow-jobs.mjs` читает его по пути от
+себя, без него доказательство Validate кандидата — `failed (#622)`. Исключение
+— job `model_review`: ревьюер исполняет тесты и скрипты материала, это его
+работа, а не конвейера. Следствие для задач, меняющих сам конвейер: их
+слияние судит версия `dev`, новая начинает действовать со следующей задачи.
+Правка контракта доказательства Validate (имена потребляемых job
+`validate.yml`, политики `ci-proof.mjs`, #622) пишется совместимой с
+собственным слиянием — старое имя потребляемой job живёт до слияния, — иначе
+задачу сливает владелец.
+
 **Красная ночь** (#736). Красный ночной Validate — сигнал с адресатом: job
 `night_red` в `_nightly.yml` (`scripts/night-red.mjs`) пишет по одному
 комментарию в каждую задачу, чьи коммиты классов A/B вошли в `dev` после