Show egress/ingress levels in the registry; freeze checks at the verdict

Registry: the "last result" column now also shows, per level (egress,
ingress), how many of the recorded checks of the latest cycle succeeded, split
by check family (tcp-22 and tcp-443 are both "tcp"). One grouped query per
chunk of addresses; new fields last_cycle_id, egress, ingress in
GET /admin/registry; the dashboard renders them under the verdict.

Verdict integrity (migration 0010):
- the prober is handed an address once per site and attempt, not on every
  poll, so results are no longer overwritten by later probe rounds;
- UpsertCheckIfOpen refuses writes once the address is aggregating or has its
  verdict, or for an older attempt; senders get {"ok":true,"ignored":N} and a
  result_dropped event is recorded;
- the checking window counts from checking_started_at, not from assigned_at;
- checks.recorded_at (server clock) and checks.after_verdict (flag for rows
  written after the verdict in existing data);
- the verdict rule is a pure function (computeVerdict) and the aggregated
  event carries the egress/ingress check counts.

Rebuilt bin/control-api and bin/admin-dashboard to match. Plans and summaries
are in docs/changes; README, API, USAGE, DASHBOARD and DIAGRAMS are updated.

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

docs/USAGE.md

@@ -331,7 +331,19 @@ curl -s http://<control-api>:8080/api/v1/admin/ips \
 Отсутствие ответа от источника (площадка не прислала результат до
 истечения `checking_window_seconds`) засчитывается как провал — это
 управляется настройкой `aggregation.missing_counts_as_fail` в конфиге
-control-api (по умолчанию включено).
+control-api (по умолчанию включено). Окно `checking_window_seconds`
+отсчитывается от начала проверки (состояние `checking`), а не от выдачи
+адреса валидатору, поэтому привязка Floating IP, пауза `fip_settle_seconds`
+и self-check в окно не входят.
+
+**Вердикт и проверки не расходятся.** Проверки фиксируются в момент
+вердикта: результат, пришедший после него (опоздавший), не сохраняется и не
+меняет проверки адреса — Floating IP к этому времени уже отвязан, и такая
+проверка ничего не доказывает. Каждая площадка зондирует адрес один раз за
+попытку. Отброшенные результаты видны как события `result_dropped` у адреса;
+в нормальном прогоне их нет или единицы. Недостающий результат (источник не
+прислал его вовсе) по-прежнему считается провалом, вердикт тогда не выше
+`partial`.
 
 ## Просмотр деталей и истории по конкретному адресу
 
@@ -385,6 +397,18 @@ curl -s http://<control-api>:8080/api/v1/admin/registry/203.0.113.10 | python3 -
 `/overview`, плюс он отражается в адресной строке (`?q=&status=`), так что
 отфильтрованную ссылку можно сохранить или переслать.
 
+В колонке «Последний результат» под вердиктом (`pass`/`partial`/`fail`)
+показаны два уровня последнего цикла: **Egress** (выходные проверки
+валидатора) и **Ingress** (входные проверки пробера со всех площадок) в виде
+«успешно из всего», например `Egress 5 из 5`, `Ingress 3 из 4`. Под каждым
+уровнем — то же по типам проверок (`https 3 из 3`, `icmp 2 из 2`, `tcp 2 из 3`);
+порты объединены в тип (`tcp-22` и `tcp-443` — один `tcp`), новый тип
+проверки появится в списке сам. Цвет: зелёный — все успешны, красный — ни одной,
+жёлтый — часть. Считаются записанные проверки цикла; вердикт учитывает ещё и
+недостающие результаты, поэтому при неполном наборе он может быть хуже, чем
+видно по счётчикам (подсказка при наведении). Те же данные — в
+`GET /api/v1/admin/registry` ([API.md](API.md#get-apiv1adminregistry)).
+
 **Глубина хранения.** Чтобы история не росла бесконечно на адресах,
 которые перепроверяют очень часто, можно ограничить, сколько последних
 циклов проверки хранить на каждый адрес — `history_retention_cycles` на