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/test/operation-lock.test.ts

@@ -139,6 +139,86 @@ describe("захват и освобождение", () => {
   });
 });
 
+describe("барьер покоя при захвате", () => {
+  /**
+   * Замок защищает production paths, пока жив процесс-держатель. Rollback guard
+   * firewall — отдельный systemd-объект, который свой процесс переживает, и
+   * способен вернуть прежний firewall уже посреди следующей операции.
+   */
+  test("отказ барьера не оставляет замка на сервере", async () => {
+    await expect(
+      acquireOperationLock("reconfigure", {
+        path: lockFile,
+        pid: LIVE_PID,
+        barrier: async () => {
+          throw new Error("guard предыдущей операции всё ещё вооружён");
+        }
+      })
+    ).rejects.toThrow("guard предыдущей операции всё ещё вооружён");
+
+    expect(existsSync(lockFile)).toBe(false);
+  });
+
+  test("барьер проверяется до захвата, а не после него", async () => {
+    let lockExistedAtBarrier: boolean | null = null;
+
+    await expect(
+      acquireOperationLock("install", {
+        path: lockFile,
+        pid: LIVE_PID,
+        barrier: async () => {
+          if (lockExistedAtBarrier === null) {
+            lockExistedAtBarrier = existsSync(lockFile);
+          }
+          throw new Error("pending guard");
+        }
+      })
+    ).rejects.toThrow("pending guard");
+
+    expect(lockExistedAtBarrier).toBe(false);
+  });
+
+  // Между первой проверкой и захватом умирающая предыдущая операция успевает
+  // вооружить guard, поэтому проверок две.
+  test("вторая проверка идёт уже под замком и снимает его при отказе", async () => {
+    let calls = 0;
+    const seenUnderLock: boolean[] = [];
+
+    await expect(
+      acquireOperationLock("repair", {
+        path: lockFile,
+        pid: LIVE_PID,
+        barrier: async () => {
+          calls += 1;
+          seenUnderLock.push(existsSync(lockFile));
+          if (calls === 2) {
+            throw new Error("guard вооружён между проверкой и захватом");
+          }
+        }
+      })
+    ).rejects.toThrow("guard вооружён между проверкой и захватом");
+
+    expect(calls).toBe(2);
+    expect(seenUnderLock).toEqual([false, true]);
+    expect(existsSync(lockFile)).toBe(false);
+  });
+
+  test("при спокойном барьере замок берётся обычным образом", async () => {
+    let calls = 0;
+    const lock = await acquireOperationLock("install", {
+      path: lockFile,
+      pid: LIVE_PID,
+      barrier: async () => {
+        calls += 1;
+      }
+    });
+
+    expect(calls).toBe(2);
+    expect(existsSync(lockFile)).toBe(true);
+    await lock.release();
+  });
+});
+
 describe("замок мёртвого держателя", () => {
   test("переиспользуется, а не блокирует сервер навсегда", async () => {
     writeFileSync(
@@ -235,7 +315,7 @@ describe("политика замка в CLI", () => {
 
   test("мутирующие команды выполняются под замком", () => {
     for (const command of ["install", "reconfigure", "repair"] as const) {
-      expect(cliSource).toContain(`await withOperationLock("${command}", () => ${command}(options))`);
+      expect(cliSource).toContain(`await runLifecycleOperation("${command}", () => ${command}(options))`);
     }
   });
 
@@ -245,7 +325,17 @@ describe("политика замка в CLI", () => {
    * бессмысленные ошибки по временным несоответствиям.
    */
   test("doctor исключён против мутирующих операций", () => {
-    expect(cliSource).toContain('await withOperationLock("doctor", () => doctor(options))');
+    expect(cliSource).toContain('await runLifecycleOperation("doctor", () => doctor(options))');
+  });
+
+  // Замок и барьер покоя обязаны идти вместе: замок ничего не знает про
+  // systemd-таймер, переживший своего держателя.
+  test("захват замка всегда сопровождается барьером покоя", () => {
+    expect(cliSource).toContain("{ barrier: assertNoPendingRollbackGuard }");
+    const direct = cliSource.split("withOperationLock(").length - 1;
+    // Единственное употребление — внутри runLifecycleOperation: иначе появился
+    // бы путь захвата замка мимо барьера.
+    expect(direct).toBe(1);
   });
 
   // Отказ обязан произойти ДО первой мутации. Замок оборачивает вызов команды