core(M2): машина состояний сессии Ayla LAN + mock-модуль + интеграционные сценарии

- session.{hpp,cpp}: state machine (idle/registering/online/recovering/
  offline/key_error); httpd-обработчики key_exchange (200/426/412, re-key
  прозрачно), commands (одна команда, 206/200, envelope, глобальный seq_no),
  datapoint (unpack -> PropertyEvent / 401+тишина 50с для re-key-восстановления);
  сессионный поток: local_reg POST?dsn/PUT (local_ip_for), keep-alive, backoff
  x1.6->60с, 503->offline/NoSlot, activation-timeout->recovering, delete_session
  с ожиданием выдачи; очередь с coalescing + batch; телеметрия; колбэки из
  двух потоков с задокументированным контрактом; буферы datapoint-пути в Impl.
- platform: local_ip_for (UDP-connect) posix+esp-idf; стек httpd 24576
  (переполнение 16КБ поймано gdb на Release).
- mock_ac.py: мок-модуль, stdlib-only чистый python AES-256 (свёрстан с
  pycryptodome); сценарии: 503, no-poll, rekey-every, stale-gap (эмуляция
  'вернувшегося' приложения), fail-pushes (битая подпись), garbage-pushes
  (обрыв блока), break-outbound (исходящий десинк -> модуль ре-кает на
  local_reg, как probe1-3), push-every, fail-first-ke.
- session_runner + test_session_mock.py: 9 сценариев через ctest, включая
  самосинхронизацию CBC и восстановление после исходящего десинка.
- Прибор AP-WC1E: активация <=1с; re-key семантика ИСПРАВЛЕНА по живым
  тестам: re-key при зазоре local_reg >= ~44-50с (не по возрасту сессии!);
  при честном keep-alive 15с сессия стабильна без re-key; PROTOCOL/LEGACY/
  PLAN обновлены; восстановление = тишина >порога + возврат.
- CI: 7/7 x3 (gcc-Rel, gcc-ASan/UBSan, clang); ESP-IDF esp32 build complete.
Ревью под-агентом: 2 круга (стек httpd, залипание состояний, dangling cfg,
физика десинка) — APPROVED.

docs/LEGACY_ANALYSIS.md

@@ -30,13 +30,14 @@
 ### 2.1. [ГЛАВНАЯ ПРИЧИНА «РАССИНХРОНИЗАЦИИ»] Keep-alive 1200 с вместо 10–15 с
 
 `notifier.py:_KEEP_ALIVE_INTERVAL = 1200.0`. APK: 10 с (или `lan.json:keepAlive/3`).
-Проверено на приборе: **единственный механизм восстановления после расхождения
-CBC-цепочек — принудительный re-key, который модуль делает при получении
-`local_reg` для сессии старше ≈44 с. Ответы 400/401 модуль игнорирует.**
-Следствие для legacy: любая потерянная пара запрос-ответ/обрыв соединения →
-обе стороны «глохнут» на срок до 20 минут (до следующего local_reg). Наблюдаемый
-симптом «перестаёт понимать кондиционер» с самопроизвольным восстановлением —
-именно это.
+Проверено на приборе: **модуль игнорирует 400/401 на свои POST; переkey
+происходит при `local_reg` после зазора ≥ ~44–50 с от предыдущего** (при
+keep-alive 10–15 с re-key вообще не происходит). Следствие для legacy: любая
+потерянная пара запрос-ответ → обе стороны «глохнут» до следующего local_reg
+(до 20 минут), который завершится re-key — наблюдаемый симптом «перестаёт
+понимать кондиционер, потом сам чинится» — именно это. Корректная стратегия
+для новой реализации: при ошибке расшифровки — пауза ~50 с, затем local_reg
+(re-key гарантирован).
 
 Дополнительно: длинные паузы между local_reg держат сессию «полуживой»
 (модуль не видит keep-alive, но слот может удерживаться), и конфликт за