Retry a failed self-check on another validator; add the self-check failure ceiling

A validator that failed the self-check of an address no longer gets that address
again in the current round (ClaimNextQueued skips it); the validator itself stays
in service and takes all other addresses. The verdict fail is set when the number
of failed self-checks of an address reaches settings.self_check_max_attempts
(1..50, default 5, independent of the number of validators); max_retries and
retry_count are no longer used for self-check. If every working validator has
already failed the address, a new round starts and the exclusions lapse.

Migration 0012: ip_self_check_failures (permanent history per registry address),
ip_queue.sc_failures and sc_round_start_cycle (cycle_id is used instead of
attempt_number, which restarts when a queue row is recreated), the setting.
db.FailSelfCheck does it in one transaction; re-submission starts a new series.
API: self_check_max_attempts in GET/PUT /admin/config/orchestrator,
self_check_failed_on in /admin/ips/{ip} and /admin/registry/{ip}. Dashboard: the
field on /settings and the line "Self-check не прошёл на: ..." on the address
pages. Docs, plan and summary in docs/changes/.

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

docs/USAGE.md

@@ -33,6 +33,7 @@
 - [Принудительная остановка проверки](#принудительная-остановка-проверки)
 - [Удаление адресов из очереди](#удаление-адресов-из-очереди)
 - [Пауза перед self-check (fip_settle_seconds)](#пауза-перед-self-check-fip_settle_seconds)
+- [Повтор после сбоя self-check](#повтор-после-сбоя-self-check)
 - [Частые проблемы и что с ними делать](#частые-проблемы-и-что-с-ними-делать)
 
 ## Как устроена работа с системой
@@ -306,8 +307,9 @@ curl -s http://<control-api>:8080/api/v1/admin/ips \
   оператора: годится ли адрес для данного случая использования.
 - **`fail`** — либо ни одна проверка не прошла, либо адрес вообще не
   дошёл до стадии проверок (например, self-check не подтвердился —
-  трафик валидатора не пошёл через назначенный FIP — и попытки
-  исчерпались). Смотрите `events` по этому адресу (см. ниже), чтобы
+  трафик валидатора не пошёл через назначенный FIP — и число провалов
+  достигло потолка `self_check_max_attempts`, см.
+  [«Повтор после сбоя self-check»](#повтор-после-сбоя-self-check)). Смотрите `events` по этому адресу (см. ниже), чтобы
   понять, на каком шаге и почему.
 - **`cancelled`** — проверку остановил оператор через `POST
   /api/v1/admin/ips/{ip}/cancel` (`State` при этом — `failed`), а не
@@ -774,6 +776,37 @@ curl -s -X POST http://<control-api>:8080/api/v1/admin/ips/clear
 всё» — каждая с подтверждением, явно предупреждающим о необратимости
 (см. [DASHBOARD.md](DASHBOARD.md)).
 
+## Повтор после сбоя self-check
+
+Если self-check адреса не прошёл на валидаторе N, адрес возвращается в
+очередь, но **этому же валидатору больше не выдаётся**: повтор достаётся
+другому. Правило действует только для этого адреса. Валидатор N не
+блокируется и не помечается неисправным, он продолжает брать остальные
+адреса. Так один временно неисправный валидатор (например, у него не
+работает трансляция плавающего IP) не расходует все попытки адреса.
+
+Итог `fail` ставится, когда число проваленных self-check у адреса достигло
+потолка **«Потолок провалов self-check на адрес»** (`self_check_max_attempts`,
+по умолчанию 5; `/settings` или `PUT /api/v1/admin/config/orchestrator`,
+допустимо 1…50). Потолок не зависит от числа валидаторов и действует на
+следующих повторах без перезапуска. Если все рабочие валидаторы
+(`idle`, `assigned`, `checking`) уже провалили адрес, а потолок не достигнут
+(валидаторов меньше потолка, в том числе один), исключения сбрасываются и
+повторы продолжаются до потолка.
+
+Исключение создаёт только проваленный self-check. Ошибка привязки
+плавающего IP, потеря валидатора и истечение лизинга исключений не создают и
+идут по `orchestrator.max_retries`, как раньше. Поле
+`orchestrator.max_self_check_retries` в YAML больше не используется.
+
+Ручная перепроверка или повторная постановка адреса начинает серию заново
+(счётчик сбоев обнуляется). История сбоев хранится постоянно (таблица
+`ip_self_check_failures`) и отдаётся в поле `self_check_failed_on` ответов
+`GET /admin/ips/{ip}` и `GET /admin/registry/{ip}`; на страницах `/ips/{ip}` и
+`/registry/{ip}` показана строка «Self-check не прошёл на: …». В журнале
+событий при повторе появляется `validator_excluded`. Показ на странице
+аналитики — отдельный следующий шаг.
+
 ## Пауза перед self-check (fip_settle_seconds)
 
 Как только Floating IP привязывается к валидатору, control-api по
@@ -833,6 +866,7 @@ https://api.ipify.org`) и логи `journalctl -u validator-agent` на пре
 
 **Адрес постоянно проваливает self-check (не зависает, а именно
 возвращается в очередь снова и снова).**
+См. также [«Повтор после сбоя self-check»](#повтор-после-сбоя-self-check): повторы идут на других валидаторах, а список «Self-check не прошёл на: …» показан на странице адреса.
 Смотрите `events` по адресу (`GET /api/v1/admin/ips/{ip}`) — в детали
 события `self_check_result` будет указан обнаруженный исходящий адрес.
 Если он не совпадает с ожидаемым — вероятно, на ВМ-валидаторе есть другой