Шаг 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/STEP4_PUBLIC_STATELESS_ASSESSMENT.md

@@ -189,6 +189,15 @@ packet-in/packet-out по своей neigh-таблице (§4.3, §8.2), но
 интеграция с тем, как EVPN-фабрика публикует MAC-привязки, чтобы control plane
 HPNN получал их не вручную, а из фабрики.
 
+> **Обновление (шаг 5, [STEP5_SUMMARY.md](STEP5_SUMMARY.md)):** первая часть
+> этого пробела закрыта — `hcd` резолвит MAC членов пула динамически через
+> обычный ARP ядра, статических `BE*_MAC` в таблице 21 больше нет. Это не
+> решает вопрос EVPN-фабрики целиком: `hcd` резолвит MAC в пределах L2-домена,
+> видимого узлу напрямую (те же hcif-порты, что и для health-проб), а не через
+> интеграцию с EVPN Type-2. Если фабрика доставляет сегмент до узла как один
+> L2-домен (что и предполагает текущая архитектура), тот же ARP-путь работает
+> без изменений; отдельная интеграция с control plane EVPN остаётся вне рамок.
+
 ## 9. Итоговая сводка условий и рисков
 
 | # | Пункт | Тип | Статус |