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/PROTOCOL.md

@@ -216,15 +216,21 @@ GET http://<ip приложения>:<порт>/local_lan/commands.json
    один «пустой» опрос `commands.json` — это признак принятой сессии.
 2. `local_reg` от endpoint'а с живой сессией **моложе ~40 с** → только
    keep-alive, без key exchange.
-3. `local_reg` от endpoint'а с сессией **старше ~44 с** → модуль принудительно
-   инициирует новый key exchange (ротация сессионных ключей). Т.е. при штатном
-   keep-alive каждые 10–15 с ключи ротируются примерно каждые 45–60 с.
-   `time_1` модуля — тикающий счётчик с шагом ≈10 нс (аптайм); порог,
-   вероятно, 44 с в этих единицах либо просто 4.4e9 тиков.
+3. `local_reg` при **зазоре ≥ ~44–50 с** от предыдущего local_reg →
+   модуль принудительно инициирует новый key exchange («вернувшееся»
+   приложение получает свежие ключи). При штатном keep-alive каждые 10–15 с
+   re-key НЕ происходит — сессия живёт сколь угодно долго (проверено:
+   100 с при 15 с keep-alive — 0 re-key; 125 с при 50 с keep-alive — 3 re-key,
+   оба без потерь). `time_1` модуля — тикающий счётчик с шагом ≈10 нс (аптайм);
+   порог, вероятно, 4.4e9 тиков (~44 с) от последнего local_reg.
 4. **Ответы 401/400 на POST модуля игнорируются**: сессия продолжает работать,
-   re-key не вызывается. Единственный механизм восстановления после расхождения
-   CBC-цепочек — принудительный re-key по `local_reg` (п. 3). Поэтому интервал
-   keep-alive = интервал потенциального «зависания» при десинхроне.
+   re-key не вызывается. Восстановление после расхождения CBC-цепочек —
+   намеренная «тишина» приложения на > порога из п. 3 с последующим
+   `local_reg`: модуль сочтёт приложение вернувшимся и ре-кает. Т.е. стратегия
+   самовосстановления: при ошибке расшифровки — пауза keep-alive ~50–60 с,
+   затем возобновить (проверено на приборе). Отдельный случай — бракованная
+   подпись при живой цепочке (сообщение расшифровано, подпись не сошлась):
+   цепочка НЕ расходится, следующий push восстанавливает работу без re-key.
 5. `delete_session` освобождает слот немедленно; следующий `local_reg` того же
    endpoint'а создаёт новую сессию.
 6. Наблюдавшийся (не воспроизведённый повторно) режим отказа: модуль отвечает
@@ -316,11 +322,12 @@ data: {"id":"<id команды>","ack_status":200,"ack_message":0,"dsn":"..."}
 
 * **Потеря CBC-цепочки** (§3.4): модуль не может расшифровать ответ приложения /
   приложение не может расшифровать push модуля. Ответы 401/400 на POST модуля
-  **игнорируются** — модуль продолжает слать в «сломанный» канал. Восстановление
-  происходит только когда очередной `local_reg` (по возрасту ≥ ~44 с или от
-  нового endpoint'а) вызовет новый key exchange. Следствие: **интервал
-  keep-alive = максимальное время «мёртвой» сессии при десинхроне**
-  (10–15 с — незаметно; 1200 с как в legacy-скрипте — 20 минут глухоты).
+  **игнорируются** — модуль продолжает слать в «сломанный» канал. Восстановление:
+  приложение замолкает на > ~44–50 с (порог «возврата» из п. 4.4.3) и шлёт
+  `local_reg` — модуль переkey'ается. Реализация ядра: при ошибке расшифровки
+  пауза keep-alive ~50 с, затем возобновление. В legacy-скрипте пауза получалась
+  «бесплатно» из-за keep-alive 1200 с: каждый цикл завершался re-key при
+  возврате — потому рассинхрон «сам чинился» через ~20 минут.
 * **Смена lanip_key** (`key_id` не совпал): теоретический путь по APK — 412 +
   `refreshLanConfig()` из облака. За 5 лет эксплуатации прибора ротации ключа
   не наблюдалось ни разу; ключ, по-видимому, зашит в модуль, облако лишь хранит