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) — там же.

CHANGELOG.md

@@ -123,6 +123,45 @@ Hardening-проход перед релизом `1.0.0`. Основная те
   отказавших, но принцип «восстановить максимум» на уровне файлов не
   выполнялся.
 
+- **Отказ записи маркера `auto-rollback-fired` оставался незамеченным.**
+  Инвариант фиксации — «маркера нет и юниты `inactive` ⇒ guard не сработал» —
+  верен только при дополнительном условии «guard способен записать маркер».
+  Пока `rc=0` стояло ПОСЛЕ создания маркера, отказ записи (заполненный tmpfs
+  `/run`, read-only ФС) не влиял ни на что: скрипт успешно восстанавливал
+  прежний firewall, завершался кодом 0, юнит уходил в `inactive`, маркера не
+  было — и операция фиксировала успех после реально сработавшего отката.
+  Теперь у факта срабатывания два независимых канала: маркер и отказ юнита.
+
+  Отдельно: маркер создаётся `touch`, а не `: >file`. Двоеточие — special
+  builtin POSIX, и ошибка перенаправления на нём обязана завершить
+  неинтерактивный shell целиком; в dash, который на Debian и есть `/bin/sh`,
+  скрипт умер бы ДО восстановления firewall.
+
+- **Новая операция могла начаться, пока guard предыдущей ещё вооружён.** Замок
+  и guard вводились по отдельности и оставляли дыру на своём стыке. Замок
+  действует, пока жив процесс-держатель; guard — отдельный объект systemd,
+  который свой процесс переживает:
+
+  ```text
+  A берёт замок -> применяет firewall -> вооружает guard на 45 секунд
+  A аварийно умирает
+  B берёт замок и начинает менять production paths
+  guard A срабатывает и возвращает firewall, который был ДО A
+  ```
+
+  Случай с `SIGTERM`/`SIGHUP` при этом хуже, чем `kill -9`: обработчик снимает
+  замок сам, поэтому проверка живости держателя не видит вообще ничего, а
+  таймер остаётся. Введён барьер покоя, через который проходит каждый захват
+  замка — и PHASE 0 установщика тоже. Условие старта стало «у предыдущей
+  операции не осталось исполнителей, способных изменить систему».
+
+- **Восстановление `UnitFileState` обещало точность, которой не давало.**
+  `systemctl enable --runtime` не удаляет постоянную ссылку, поэтому
+  «восстановление» состояния `enabled-runtime` оставляло юнит включённым в
+  обоих scope'ах. Теперь восстанавливаются `enabled` и `disabled` — состояния,
+  которые операция реально меняет, — а остальные явно называются оператору и
+  не трогаются.
+
 ### Исправлено — целостность отката
 
 - **Данные для отката уничтожались до фиксации успеха.** Успешный install