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

orchestrator/src/lib/operationLock.ts

@@ -85,6 +85,20 @@ export type LockOptions = {
   isProcessAlive?: (pid: number) => boolean;
   /** PID текущего процесса. Переопределяется тестами. */
   pid?: number;
+  /**
+   * Барьер покоя: проверка, что у предыдущей операции не осталось асинхронных
+   * исполнителей, способных изменить систему.
+   *
+   * Замок сам по себе такой гарантии не даёт и дать не может. Он защищает
+   * production paths, пока жив процесс-держатель, а rollback guard firewall —
+   * отдельный systemd-объект, который свой процесс переживает. Поэтому
+   * условие начала операции не «PID предыдущей мёртв», а «предыдущая больше не
+   * имеет исполнителей».
+   *
+   * Вызывается ДВАЖДЫ — до попытки захвата и сразу после успешного: между
+   * этими моментами умирающая предыдущая операция успевает вооружить guard.
+   */
+  barrier?: () => Promise<void>;
 };
 
 export function renderLockRecord(record: LockRecord): string {
@@ -337,12 +351,28 @@ export async function acquireOperationLock(
     nonce: newNonce()
   };
 
+  // Барьер до захвата: отказать раньше, чем на сервере появится наш замок.
+  await options.barrier?.();
+
   mkdirSync(dirname(path), { recursive: true });
 
   for (let attempt = 0; attempt < 2; attempt += 1) {
     if (await writeLockFile(path, record)) {
       installExitHandlers();
       heldLocks.set(path, record.nonce);
+
+      // И повторно — уже под замком. Окно между проверкой и захватом невелико,
+      // но именно в нём умирающая предыдущая операция успевает вооружить guard,
+      // а барьер существует ровно против этого.
+      if (options.barrier) {
+        try {
+          await options.barrier();
+        } catch (error) {
+          releaseSync(path, record.nonce);
+          throw error;
+        }
+      }
+
       info(`operation lock acquired: ${path} (${command}, pid ${pid})`);
       return {
         command,