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/11-testing-and-acceptance.md

@@ -257,6 +257,18 @@ HYSTERIA_BIN=/usr/local/bin/hysteria ./tools/test/e2e-hysteria.sh
 - скрипт не маскирует ошибки (`|| true`, `2>/dev/null`), не использует `set -e`
   и возвращает накопленный `rc`: каждый сообщённый отказ поднимает код возврата,
   поэтому частичное восстановление уходит в `failed`, а не в молчаливый `0`;
+- `rc` объявляется **до** создания маркера, а ранний выход возвращает его, а не
+  жёсткий `0`. Инвариант фиксации верен только при условии «guard способен
+  записать маркер»: пока `rc=0` стояло после, отказ записи (заполненный tmpfs
+  `/run`, read-only ФС) не влиял ни на что — скрипт восстанавливал прежний
+  firewall, завершался нулём, и операция фиксировала успех после реально
+  сработавшего отката. Теперь у факта два канала: маркер и отказ юнита;
+- маркер создаётся `touch`, а не `: >file`: двоеточие — special builtin POSIX,
+  и ошибка перенаправления на нём обязана завершить неинтерактивный shell
+  целиком, то есть в dash скрипт умер бы **до** восстановления firewall;
+- поведенчески проверяется ранний путь скрипта — он заканчивается до первой
+  команды восстановления и потому безопасен для запуска: при доступном каталоге
+  маркер создаётся и выход нулевой, при недоступном — выход ненулевой;
 - скрипт не трогает `nftables.service`: у него `ExecStop=nft flush ruleset`, и
   остановка сервиса стёрла бы только что восстановленные правила;
 - скрипт разбирается **настоящим** shell-парсером. Парсер принимается только
@@ -294,6 +306,10 @@ HYSTERIA_BIN=/usr/local/bin/hysteria ./tools/test/e2e-hysteria.sh
 - захват под read-only guard отказывает, наблюдение — разрешено. Замок берётся
   до включения guard, и проверка существует, чтобы перенос захвата внутрь
   читающей фазы отказал громко, а не записал файл молча;
+- барьер покоя вызывается **дважды** — до захвата и уже под замком, — а отказ
+  второй проверки снимает замок за собой. Замок сам по себе гарантии не даёт:
+  он защищает production paths, пока жив держатель, а rollback guard переживает
+  свой процесс;
 - политика CLI закреплена структурно: `install`/`reconfigure`/`repair`/`doctor`
   вызываются только под замком, `status`/`diagnostics` его не берут, но сообщают
   об идущей операции, а `preflight-install` отказывает до собственных проверок.
@@ -1083,14 +1099,61 @@ reconfigure идёт -> diagnostics collect
   → в stderr есть note об идущей операции
 ```
 
-Отдельно проверяется, что замок не переживает своего держателя:
+Отдельно проверяется, что замок не переживает своего держателя. **Важно:**
+прерывать операцию нужно ДО шага `firewall`, иначе проверяется уже сценарий
+D1h, а не этот.
 
-1. `reconfigure --apply` прерывается `Ctrl+C` — замок снят, следующий
-   `reconfigure` проходит;
-2. процесс убивается `kill -9`, после чего следующая операция сообщает
-   `is held by … which is no longer running; reclaiming it` и продолжает;
+1. `reconfigure --apply` прерывается `Ctrl+C` на шаге `config generation` —
+   замок снят, следующий `reconfigure` проходит;
+2. процесс убивается `kill -9` на том же шаге, после чего следующая операция
+   сообщает `is held by … which is no longer running; reclaiming it` и
+   продолжает;
 3. `/run/lock/hy2xs-orchestrator.lock` не остаётся после завершения операции.
 
+## D1h. Аварийно умершая операция с вооружённым guard
+
+Проверяется на рабочей установке. Это стык двух защитных механизмов, и до его
+закрытия каждый из них по отдельности работал правильно, а вместе они
+оставляли дыру.
+
+Замок защищает production paths, пока **жив процесс-держатель**. Rollback guard
+firewall — отдельный systemd-объект, который свой процесс переживает. Поэтому:
+
+```text
+A берёт замок -> применяет firewall -> вооружает guard на 45 секунд
+A аварийно умирает
+B берёт замок (снятый обработчиком сигнала либо переиспользованный)
+B начинает менять production paths
+guard A срабатывает и возвращает firewall, который был ДО A
+```
+
+Уникальные `op-id` здесь не помогают: каталоги копий разные, а
+`/etc/nftables.conf`, `/etc/nftables.d/hy2xs.nft` и ruleset в ядре — общие.
+
+Сценарий:
+
+1. `reconfigure --apply` доводится до появления в журнале
+   `firewall rollback guard armed`;
+2. процесс убивается `kill -9` (замок остаётся устаревшим) — и, отдельным
+   прогоном, `kill -TERM` (замок снимается обработчиком, то есть его вообще не
+   будет; это и есть случай, который проверка живости держателя не ловит);
+3. **до истечения 45 секунд** запускается `repair` или `reconfigure --apply`;
+4. новая операция обязана отказать:
+
+```text
+previous HY2XS operation is no longer running, but its firewall rollback guard
+is still armed: hy2xs-fw-rollback-<op-id>.timer (active)
+```
+
+5. отказ происходит **до** снятия резервной копии и до первой мутации;
+6. `install.sh` в том же окне отказывает на PHASE 0 по той же причине;
+7. после срабатывания guard (`hy2xs-fw-rollback-*` больше не `active`)
+   `repair` проходит.
+
+Обратная проверка: на сервере без вооружённого guard барьер молчит и ни одну
+операцию не задерживает, а `failed` от уже отработавшего guard **не** считается
+непокоем — иначе он заблокировал бы `repair`, которым и чинят последствия.
+
 ## D1g. Успешная установка не оставляет следов транзакции
 
 Проверяется на чистом хосте, обычной успешной установкой. Это обратная проверка
@@ -1204,6 +1267,11 @@ hy2xs-orchestrator doctor
    - `status`/`diagnostics` не блокируются и сообщают об идущей операции;
    - замок не переживает своего держателя.
 
+4c. **Аварийная смерть с вооружённым guard** (сценарий D1h):
+   - новая операция отказывает, пока `hy2xs-fw-rollback-*` ещё активен, в том
+     числе когда замка не осталось вовсе;
+   - после срабатывания guard `repair` проходит.
+
 5. **Partial install + repair**:
    - состояние `install-state` фиксирует промежуточную фазу;
    - `repair` завершает граф до `installed=true`.
@@ -1295,3 +1363,6 @@ hy2xs-orchestrator doctor
 65. откат восстанавливает `enabled`/`active` состояние `nftables.service`, а не только файлы правил
 66. операции жизненного цикла сериализованы эксклюзивным замком: вторая операция отказывает до первой мутации, а `status`/`diagnostics` не блокируются
 67. замок снимается при любом завершении держателя, включая `Ctrl+C`, SIGTERM и обрыв SSH; замок мёртвого держателя переиспользуется безопасно
+68. новая операция не начинается, пока у предыдущей остаётся вооружённый rollback guard: условие старта — «у предыдущей нет исполнителей, способных изменить систему», а не «её PID мёртв»
+69. отказ записи маркера `auto-rollback-fired` не может привести к фиксации успеха: он переводит юнит guard в `failed`, а `failed` фиксацию запрещает
+70. восстановление `UnitFileState` у `nftables.service` не обещает точности, которой не даёт: восстанавливаются `enabled`/`disabled`, остальные состояния называются оператору и не трогаются