Добавить ESP pairing через доверенные сессии

Dev_Docs/API/02_Authentication_API.md

@@ -2,7 +2,7 @@
 
 Этот файл описывает именно этапы авторизации клиента, то есть как создать новую сессию и как войти в уже существующую.
 
-Здесь четыре метода:
+Здесь четыре базовых метода обычной авторизации:
 
 - `AuthChallenge`
 - `CreateAuthSession`
@@ -36,6 +36,16 @@
 
 Ниже в документе сначала описан сценарий, а потом зафиксированы точные форматы запросов и ответов.
 
+Отдельно появился новый серверный сценарий pairing через доверенный homeserver/ESP. Он не заменяет обычный вход и описан в:
+
+- `Dev_Docs/Протоколы/ESP_Pairing_и_режимы_подключения.md`
+
+Кратко:
+
+- `AuthChallenge/CreateAuthSession` и `SessionChallenge/SessionLogin` остаются каноническими потоками обычной авторизации;
+- pairing через ESP идёт отдельными `op` и только подготавливает безопасное добавление новой сессии;
+- решение об одобрении pairing принимает любая уже авторизованная доверенная сессия пользователя.
+
 ## 1. Поток авторизации
 
 Поддерживаются два сценария:
@@ -289,6 +299,30 @@ SESSION_LOGIN:{sessionId}:{timeMs}:{nonce}
 
 ---
 
+## 6. Pairing через homeserver/ESP
+
+Новые `op`, относящиеся к этому сценарию:
+
+- `UpsertEspPairingSettings`
+- `StartEspPairing`
+- `ListEspPairingRequests`
+- `ApproveEspPairing`
+- `RejectEspPairing`
+- `GetEspPairingStatus`
+
+В этом потоке:
+
+- новое устройство не владеет `deviceKey` и не проходит обычный `CreateAuthSession`;
+- пароль проверяется сервером только как фильтр;
+- решение об одобрении принимает уже авторизованная доверенная сессия пользователя;
+- сервер не расшифровывает `encryptedPayload` и не становится источником приватных ключей.
+
+Точные форматы этих операций см. в `03_Session_Management_API.md` и в протокольном документе:
+
+- `Dev_Docs/Протоколы/ESP_Pairing_и_режимы_подключения.md`
+
+---
+
 ## 6. Пример ошибки
 
 ```json