docs(har): org2.har — де-аллокация = меньший count в vIPConfigure; операция pending (блок детей)

docs/HAR_SNAT_MODIFY_FINDINGS.md

@@ -30,11 +30,15 @@
    - Включить SNAT: `ipSpaceName = <имя ipSpace из org>`.
    - Выключить: `ipSpaceName = "no-needed"`.
 2. ✅ **Каноническое «SNAT выключен» = `no-needed`.** Подтверждено: в UI (Edge → Modify → поле «ip Space для VIP», параметр `ipSpaceName`) текущее значение показывается как `no-needed`. Reverse для SNAT = `modify` с `ipSpaceName="no-needed"` → delete SNAT-модификатора можно реализовать не как no-op. (`""` из `ipSpace0.har` — не каноническое, а промежуточное состояние.)
-3. ❌ **Де-аллокация IP в org (reverse) в HAR НЕ записана** — есть только добавление. Payload удаления/уменьшения не подтверждён.
+3. 🟡 **Де-аллокация IP в org — попытка зафиксирована (`org2.har`, 2026-09-22):** UI отправил `modify` с
+   `vIPConfigure=[{"name":"internet-ipv4-v1","count":"2"}]` (count уменьшен с 3 до 2).
+   HTTP-ошибки НЕТ, но операция осталась в `isPending:true` — не выполнилась (согласуется с ограничением ниже).
+   **Вывод:** payload де-аллокации = ТА ЖЕ структура `vIPConfigure`, только меньше `count` (не отдельная операция).
+   Точная семантика «удалить совсем» (`count=0` или опустить элемент) не подтверждена.
    🔴 **Ограничение (подтверждено):** уменьшить/удалить ipSpace в `vcOrg` **нельзя, пока существуют дочерние инстансы** (VDC/Edge/кластер).
    Следствие: reverse возможен только ПОСЛЕ уничтожения детей → порядок destroy критичен:
    `кластер → SNAT-модификатор (no-needed) → org IP de-alloc → edge → vdc → org`.
-   Чтобы снять payload де-аллокации, нужен чистый org без детей (или плановый teardown).
+   Чтобы снять payload «удалить совсем», нужен чистый org без детей (или плановый teardown).
 
 ## Побочные факты