fix(orchestrator): закрыть два остатка на стыке guard и замка операций

Оба дефекта — в механизмах, введённых предыдущими коммитами, и оба относятся к
гарантиям, ради которых эти механизмы вводились.

1. Отказ записи `auto-rollback-fired` оставался незамеченным.

Инвариант фиксации "маркера нет и юниты inactive => guard не сработал" верен
только при дополнительном условии "guard способен записать маркер". Пока `rc=0`
стояло ПОСЛЕ создания маркера, отказ записи (заполненный tmpfs /run, read-only
ФС) не влиял ни на что: скрипт успешно восстанавливал прежний firewall,
завершался кодом 0, юнит уходил в inactive, маркера не было — и операция
фиксировала успех после реально сработавшего отката.

`rc` объявляется до первой операции, включая создание маркера, а ранний выход
возвращает его вместо жёсткого `exit 0`. У факта срабатывания появилось два
независимых канала: маркер и отказ юнита, потому что на пути фиксации успеха
допустим ровно один ActiveState — inactive.

Заодно маркер создаётся `touch`, а не `: >file`: двоеточие — special builtin
POSIX, ошибка перенаправления на нём обязана завершить неинтерактивный shell
целиком, и в dash скрипт умер бы ДО восстановления firewall.

2. Новая операция могла начаться, пока guard предыдущей ещё вооружён.

Замок действует, пока жив процесс-держатель. Guard — отдельный объект systemd,
переживающий свой процесс:

    A берёт замок -> применяет firewall -> вооружает guard на 45s
    A аварийно умирает
    B берёт замок и начинает менять production paths
    guard A срабатывает и возвращает firewall, который был ДО A

Случай SIGTERM/SIGHUP хуже, чем kill -9: обработчик снимает замок сам, поэтому
проверка живости держателя не видит вообще ничего, а таймер остаётся.

Введён барьер покоя `assertNoPendingRollbackGuard`, через который проходит
каждый захват замка — дважды, до и после, потому что между ними умирающая
операция успевает вооружить guard, — и PHASE 0 установщика. Непокоем считаются
active/activating/deactivating/reloading; `failed` и `inactive` — покой, иначе
барьер блокировал бы `repair`, которым чинят последствия.

Плюс P1: восстановление UnitFileState у nftables.service больше не обещает
точности, которой не даёт. `enable --runtime` не удаляет постоянную ссылку,
поэтому "восстановление" enabled-runtime оставляло юнит включённым в обоих
scope. Восстанавливаются enabled/disabled — то, что операция реально меняет, —
остальные состояния называются оператору и не трогаются.

Тесты: поведенческая проверка раннего пути rollback-скрипта настоящим shell
(ветка заканчивается до первой команды восстановления и безопасна для запуска),
проверка двойного вызова барьера и снятия замка при его отказе, структурные
инварианты. Приёмка и docs (D1h, уточнение D1f) — там же.

docs/07-systemd-and-firewall.md

@@ -135,6 +135,13 @@ smoke: smoke на медленном, но исправном сервере м
 systemd, `stop` возвращает 5, и этот исход неотличим от успешного снятия
 взведённого таймера.
 
+У факта срабатывания два независимых канала, и это не избыточность. Маркер —
+обычный. Отказ юнита — аварийный: если записать маркер не удалось (заполненный
+tmpfs `/run`, read-only ФС), скрипт поднимает код возврата, юнит уходит в
+`failed`, а `failed` на пути фиксации успеха запрещён так же, как и маркер.
+Без второго канала инвариант был бы верен лишь при дополнительном условии
+«guard способен записать маркер», которого никто не гарантирует.
+
 Сам rollback-скрипт восстанавливает файлы и ruleset, накапливает код возврата и
 уходит в `failed` при частичном восстановлении. Состояние `nftables.service` он
 сознательно не трогает: у этого юнита `ExecStop=/usr/sbin/nft flush ruleset`, то
@@ -142,6 +149,27 @@ systemd, `stop` возвращает 5, и этот исход неотличи
 active восстанавливает обычный откат в процессе оркестратора, где порядок стадий
 контролируется.
 
+### Guard переживает свой процесс
+
+Guard — объект systemd, а не часть процесса оркестратора. Аварийно умершая
+операция оставляет его вооружённым, и он способен вернуть прежний firewall уже
+посреди **следующей** операции. Замок операций от этого не защищает: он
+действует, пока жив процесс-держатель.
+
+Поэтому условие начала новой операции — не «PID предыдущей мёртв», а «у
+предыдущей не осталось исполнителей, способных изменить систему». Каждый захват
+замка проходит через барьер покоя: если хоть один `hy2xs-fw-rollback-*` находится
+в состоянии `active`, `activating`, `deactivating` или `reloading`, операция
+отказывает.
+
+`inactive` и `failed` считаются покоем: отработавший guard больше ничего не
+сделает, а отказ по `failed` заблокировал бы `repair` — ровно тот инструмент,
+которым чинят последствия.
+
+Состояния `hysteria-server`, `hy2xs-admin` и `nftables.service` барьер
+сознательно не проверяет: незавершённый `systemctl restart` ничего не
+откатывает, он лишь повторяет то, что новая операция сделает сама.
+
 ### Проверка эффективного firewall
 
 `nft -c -f /etc/nftables.conf` разбирает текущий файл, каким бы он ни был, и