Enable SSH and TLS handshake on prober for TCP22 and TCP443 ports

docs/API.md

@@ -262,8 +262,10 @@ USAGE.md про состояния площадки).
 {
   "results": [
     {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "tcp-22",  "success": true, "latency_ms": 12, "checked_at": "2026-08-21T09:15:01Z", "complete": false},
+    {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "ssh",     "success": true, "latency_ms": 15, "checked_at": "2026-08-21T09:15:01Z", "complete": false},
     {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "tcp-80",  "success": true, "latency_ms": 9,  "checked_at": "2026-08-21T09:15:01Z", "complete": false},
     {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "tcp-443", "success": true, "latency_ms": 10, "checked_at": "2026-08-21T09:15:01Z", "complete": false},
+    {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "tls-443", "success": true, "latency_ms": 34, "checked_at": "2026-08-21T09:15:01Z", "complete": false},
     {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "tcp-8080","success": false,"latency_ms": 0,  "checked_at": "2026-08-21T09:15:01Z", "complete": false},
     {"ip_id": 42, "ip_address": "203.0.113.10", "check_type": "icmp",   "success": true, "latency_ms": 5,  "checked_at": "2026-08-21T09:15:01Z", "complete": true}
   ]
@@ -275,6 +277,16 @@ USAGE.md про состояния площадки).
 IP на данном проходе". До этого момента control-api не будет считать
 данные с этой площадки завершёнными.
 
+Порты `22` и `443` в `ports` — особый случай: если они присутствуют в
+списке, `prober` дополнительно к базовой `tcp-<port>`-проверке доступности
+выполняет **настоящий** протокольный чек — `ssh` (обмен SSH-банером на
+порту 22) и `tls-443` (полноценный TLS-хендшейк на порту 443)
+соответственно. Это не отдельно настраиваемые типы проверок — они
+включаются/выключаются автоматически вместе с самим портом, без
+дополнительного флага. Сертификат в `tls-443` не валидируется
+(`InsecureSkipVerify`) — проверяется только сам факт TLS-хендшейка, не
+доверие к серверу.
+
 Ответ: `{"ok": true}`.
 
 ## Служебные и административные методы

docs/USAGE.md

@@ -324,6 +324,16 @@ curl -s -X PUT http://<control-api>:8080/api/v1/admin/config/inbound-checks \
 паузой перед self-check (см. ниже): текстовое поле с портами через запятую
 и чекбокс ICMP.
 
+Порты `22` и `443` в этом списке трактуются особо: помимо базового
+TCP-connect (`tcp-22`/`tcp-443`) пробер дополнительно выполняет настоящий
+обмен SSH-банером (`ssh`) и настоящий TLS-хендшейк (`tls-443`) —
+голого открытого TCP-порта недостаточно, чтобы считать SSH/HTTPS
+рабочими. Отдельного переключателя для этих доп.проверок нет: они
+включаются и выключаются вместе с самим портом в `ports`. Если на порту
+22/443 у площадки на самом деле слушает что-то, кроме SSH/HTTPS,
+доп.проверка будет закономерно проваливаться — заведите для такого сервиса
+другой порт.
+
 > Правки через `orchestrator.inbound_checks` в `control-api.yaml` тоже
 > поддерживаются, но только как bootstrap пустой базы данных при самом
 > первом старте — как только в БД есть эта настройка (а она появляется