Manage external site-prober actions va API and Dashboard

docs/API.md

@@ -231,7 +231,11 @@ target)` в рамках текущей попытки — безопасна и
 ]
 ```
 
-Пустой список `[]`, если сейчас нечего проверять.
+Пустой список `[]`, если сейчас нечего проверять. `ports`/`icmp` — текущая
+конфигурация типов проверок пробера, одна и та же для каждого IP в ответе;
+управляется через
+[`/api/v1/admin/config/inbound-checks`](#типы-проверок-пробера-apiv1adminconfiginbound-checks)
+и меняется без рестарта control-api.
 
 ### `POST /api/v1/probers/{site_id}/results`
 
@@ -477,6 +481,33 @@ fip_settle_seconds` в `control-api.yaml` — только одноразовы
 для пустой БД; дальше источник истины — сама база, менять значение нужно
 через `PUT` выше (или страницу `/settings` в дашборде).
 
+### Типы проверок пробера: `/api/v1/admin/config/inbound-checks`
+
+Единый глобальный набор TCP-портов и флага ICMP, которые `prober`
+проверяет на каждой настроенной площадке для каждого адреса в состоянии
+`checking` — то же самое `ports`/`icmp`, что отдаётся в ответе `GET
+/api/v1/probers/{site_id}/assignments` (см.
+[«Методы для prober»](#методы-для-prober) выше). Один набор общий для всех
+площадок; список [«площадок»](#площадки-apiv1adminconfigsites) отдельно
+решает, *сколько* точек его применяют, а не что именно они проверяют.
+Пустой список портов и `icmp: false` одновременно — допустимая
+конфигурация: временно отключает inbound-проверки, не трогая список
+`sites`.
+
+| Метод | Путь | Тело | Успех | Ошибки |
+|---|---|---|---|---|
+| GET | `/api/v1/admin/config/inbound-checks` | — | `{"ports":[...],"icmp":bool}` | |
+| PUT | `/api/v1/admin/config/inbound-checks` | `{"ports":[...],"icmp":bool}` | `200` | `400`, если какой-то порт вне диапазона `1..65535` или порты повторяются |
+
+Изменение вступает в силу немедленно — как для следующего ответа `GET
+/api/v1/probers/{site_id}/assignments`, так и для агрегации уже идущих
+проверок (см. [«Управление площадками»](USAGE.md#управление-площадками-проберами)
+в USAGE.md про тот же принцип для `sites`/`targets`/`check_types`). Как и
+остальные разделы этой группы, YAML-поле `orchestrator.inbound_checks` в
+`control-api.yaml` — только одноразовый bootstrap для пустой БД; дальше
+источник истины — сама база, менять значение нужно через `PUT` выше (или
+страницу `/settings` в дашборде).
+
 ### Пример: конфигурация целиком через API, без единой строки в YAML
 
 ```bash