docs(stability): stage 7 review round 1 — correct rollback granularity to per-stage

Review finding (low, doc-only): the rollback plan said each stage is one
independently-revertable commit, but each stage is actually two commits on its
branch (feature + review-round fix, the latter often fixing a real bug), so
reverting a single commit would orphan the review-round fix. Reword the unit of
rollback to the whole STAGE (branch/PR) and spell out the revert command per merge
strategy: squash-merge -> revert the one squash commit; merge-commit -> revert -m 1
the merge; linear history -> revert the full range of the stage's commits.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/stability-verification.md

@@ -123,11 +123,21 @@ wait   # все замеры /ping должны быть заметно < 0.100
 
 ## План отката (rollback)
 
-Каждая стадия — отдельный, независимо ревертируемый коммит на своей ветке
-(`fix/stage-1-hangs` … `fix/stage-6-healthcheck`); порядок стадий = порядок деплоя.
+Единица отката — **стадия целиком**, не отдельный коммит. Каждая стадия живёт на своей
+ветке/PR (`fix/stage-1-hangs` … `fix/stage-7-verification`) и, как правило, состоит из
+**двух коммитов**: feature-коммит + фикс review-раунда (последний нередко чинит реальный
+баг — напр. fail-closed XSS в стадии 4, watchdog-gate в стадии 6). Поэтому `git revert`
+одного коммита осиротит фикс review-раунда и даст несогласованный откат. Откатывать нужно
+на гранулярности стадии; порядок стадий = порядок деплоя.
 
-- Стадии 1 и 2 — низкорисковые, деплоятся первыми; при регрессе откатываются по одной
-  (`git revert <commit>` соответствующей стадии) без затрагивания остальных.
+- **Как откатывать стадию** — зависит от того, как ветки влиты в `fix/stability`/`main`:
+  - если стадия влита **squash-merge** (один коммит на стадию) — `git revert <squash-commit>`
+    откатывает её целиком, однозначно;
+  - если стадия влита **merge-коммитом** — `git revert -m 1 <merge-commit>` откатывает весь
+    вклад ветки (оба коммита) разом;
+  - если история линейная (rebase/fast-forward) — реверт **всех** коммитов стадии
+    (`git revert <feature>..<review-fix>` включительно), а не одного.
+- Стадии 1 и 2 — низкорисковые, деплоятся первыми; откатываются независимо от остальных.
 - Стадия 3 (FileResponse) независима — реверт возвращает прежний ручной стриминг.
 - Стадия 4 требует, чтобы 4.2 откатывалась не позже 4.3 (иначе рендер-в-потоке остался бы
   без безопасного пути сохранения media id) — откатывать стадию 4 целиком.