Add self-check via control-api (self_check.methods)

control-api is hosted outside the cloud and validators reach it directly,
so it sees the floating IP as the connection's source address. New open
route GET /api/v1/agents/{id}/observed-ip returns that address (taken only
from the TCP peer; forwarding headers are ignored so a validator cannot
forge it).

The agent gets self_check.methods, a priority-ordered list of ip_echo
(unchanged) and control_api; the default stays [ip_echo]. The self-check
passes when any method confirms the address; the next method is tried on
no answer and on a mismatch. Each method has its own timeout so a hung
first method cannot starve the fallback, and control_api uses a new TCP
connection per call (a connection opened before the floating IP was
attached would keep reporting the old address).

Also: docker agent template/env, example config, docs, plan in
docs/changes, e2e script switch E2E_SELF_CHECK_METHODS, rebuilt
bin/control-api and bin/validator-agent.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

docs/USAGE.md

@@ -742,7 +742,9 @@ curl -s -X PUT http://<control-api>:8080/api/v1/admin/config/orchestrator \
 дело обычно в self-check: он запрашивает внешние (вне облака) сервисы из
 `self_check.ip_echo_urls` в конфиге валидатора (по умолчанию
 `api.ipify.org`, `ifconfig.me`) — если у ВМ-валидатора нет исходящего
-доступа в интернет к этим адресам, запрос не проходит вообще, и агент
+доступа в интернет к этим адресам, запрос не проходит вообще (при
+`self_check.methods: [control_api, ip_echo]` агент сперва спросит адрес у
+control-api, и проверка может пройти и без IP-echo), и агент
 даже не может *сообщить* результат control-api (ни успешный, ни
 неуспешный) — тогда статус реально зависает до истечения
 `orchestrator.lease_ttl_seconds`, после чего адрес возвращается в
@@ -763,7 +765,12 @@ https://api.ipify.org`) и логи `journalctl -u validator-agent` на пре
 облака (см. `self_check.ip_echo_urls`) — запрос к чему-либо внутри
 проекта (в том числе к самому control-api, если он в той же внутренней
 сети) покажет приватный адрес валидатора независимо от того, правильно
-ли привязан FIP, и всегда будет давать ложный провал.
+ли привязан FIP, и всегда будет давать ложный провал. Это относится и к
+способу `control_api` (`self_check.methods`): он корректен только когда
+валидатор ходит к control-api через внешнюю сеть; при внутреннем доступе в
+`detail` будет подсказка про приватный адрес — оставьте `ip_echo`. В
+`detail` события `self_check_result` указан сработавший способ
+(`matched (control_api)`) либо причина по каждому способу.
 
 **Площадка (`site-N`) никогда не отчитывается по конкретному IP.**
 Сперва проверьте статус самой площадки — `GET