Шаг 5: динамическое изучение MAC/ARP для бэкендов

MAC каждого члена пула больше не статическая константа в topology.env,
а резолвится демоном hcd через обычный ARP ядра — в реальном
окружении MAC бэкенда заранее не известен (сервер ещё не подключён,
NIC может замениться), топология не описывается статически, в отличие
от стенда.

hcif-порты (единственные адреса узла в ядре) уже были настоящими
L3-интерфейсами в тех же сегментах, что и бэкенды — единственное, что
мешало обычному ARP, это permanent-записи ip neigh в entrypoint.sh.
Убрав их и добавив hc/neigh.go (читает ip -json neigh show, точечно
заливает бандл в таблицу 21 на том же тикере, что и health-пробы),
получили резолвер без нового OpenFlow-контроллера.

Таблица 21 стала единственным источником MAC для обоих путей —
маршрутизируемого и коммутируемого (шаг 3): таблица 12 больше не
дублирует MAC инлайново, ct(commit) ведёт сразу в таблицу 21.

Исправлен попутно найденный баг: после apply.sh (replace-flows)
таблица 21 не восстанавливалась, поскольку syncNeighbors сравнивал
MAC с памятью демона, а не с датапасом. Добавлен force-режим по
аналогии с Agent.apply(), плюс регрессионная проверка в verify.sh.

Проверено на живом стенде: MAC всех четырёх членов резолвлен и
совпадает с реальными интерфейсами; смена MAC "железа" обнаружена и
применена без вмешательства за счёт штатного старения ARP ядра.
Регрессия: 94 из 94 проверок.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/PUBLIC_LB_DATAFLOW.md

@@ -1,11 +1,11 @@
 # Потоки данных: балансировка публичного трафика
 
-**Дата:** 2026-08-17
+**Дата:** 2026-08-18 (обновлено после шага 5 — динамический MAC/ARP)
 **Область:** путь пакета от клиента из `192.168.5.0/24` на публичный листенер
 `192.168.5.21:80` и обратно.
 **Смежный документ:** [PRIVATE_LB_DATAFLOW.md](PRIVATE_LB_DATAFLOW.md) —
 балансировка внутри приватного сегмента.
-**Источник:** `lb/pipeline.sh`, `lb/topology.env`.
+**Источник:** `lb/pipeline.sh`, `lb/topology.env`, [STEP5_SUMMARY.md](STEP5_SUMMARY.md).
 
 Публичная балансировка целиком **маршрутизируемая**: клиент и бэкенды лежат в
 разных сегментах, узел выступает L3-хопом в обе стороны, TTL уменьшается на
@@ -156,7 +156,7 @@ flowchart TD
 | 12 | `reg2` = член | `ct(commit, nat(dst=member:8080))` → t20 | без SNAT |
 | 15 | `tcp` с порта сегмента, адресован шлюзу | `ct(nat)` → t16 | обратная трансляция |
 | 20 | `/24` префиксы | `dec_ttl` + `mod_dl_src` | LPM через приоритет правила |
-| 21 | `nw_dst` = член пула | prio 100, `mod_dl_dst` + `output` | статические MAC из `topology.env` |
+| 21 | `nw_dst` = член пула | prio 100, `mod_dl_dst` + `output` | MAC резолвит `hcd` через ARP ядра (шаг 5), не `topology.env` |
 | 21 | `nw_dst` = клиент | prio 90, из `learn` | `hard_timeout` 300 с |
 
 ## 7. Где поток обрывается
@@ -173,6 +173,7 @@ flowchart TD
 
 ```bash
 make trace SRC=192.168.5.13 SPORT=41234   # путь сессии по таблицам
+make neigh                                 # MAC членов, резолвленный hcd через ARP
 make slots                                 # раскладка и per-member счётчики
 make conns                                 # записи ct
 docker compose exec lb-router lbctl flows 21