Document the Overview/Registry search+filter mechanics and layout

Adds a dedicated DASHBOARD.md subsection covering what the q/status
filter applies to on each page, why it's dashboard-side only, and the
/overview layout constraint (stats panel outside the polled block, kept
in sync via an out-of-band swap) so future layout changes don't
reintroduce the polling-wipes-the-filter bug. Cross-links added from
USAGE.md's queue-observation and registry sections.

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

docs/DASHBOARD.md

@@ -75,6 +75,39 @@ admin-dashboard -config /etc/cloud-ip-validator/admin-dashboard.yaml
   «последний запуск», а именно скользящее окно последних по времени
   завершений).
 
+### Поиск по IP и фильтр по статусу
+
+На `/overview` и `/registry` есть форма из двух полей — поиск по IP
+(подстрока, без учёта регистра) и выпадающий список статуса
+(`pass`/`partial`/`fail`/`cancelled`). Оба поля работают вместе (И, а не
+ИЛИ) и применяются целиком на стороне дашборда — `client.ListIPs`/
+`client.ListRegistry` всегда получают от `control-api` полный список,
+`internal/httpapi`/`internal/db` про фильтр вообще не знают.
+
+- **`/overview`** — фильтр действует на обе таблицы сразу («Текущая
+  проверка» и «Последние N завершённых»). Статус — это фильтр по
+  итоговому результату (`OverallResult`), поэтому выбор конкретного
+  статуса скрывает «Текущую проверку» целиком: у ещё идущих проверок
+  результата попросту нет. Панель статистики (счётчики сверху) фильтру не
+  подчиняется — это агрегаты по всей очереди, а не по видимым строкам.
+- **`/registry`** — тот же принцип, но по одной таблице (`LastResult`), и
+  значения полей отражаются в адресной строке (`?q=&status=`) через
+  `hx-replace-url` — отфильтрованную ссылку можно сохранить или переслать,
+  а обновление страницы (F5) сохраняет применённый фильтр.
+
+**Раскладка `/overview` сверху вниз**: панель статистики → форма
+фильтра → таблицы. Панель статистики и форма фильтра физически лежат
+*вне* поллящегося блока (иначе периодическое обновление стирало бы
+набранный текст/выбор — ровно то, из-за чего в своё время отказались от
+auto-refresh на `/ips`, см. git-историю). Опрашивается только блок
+`#overview-tables`; чтобы панель статистики (`#overview-stats`) при этом
+тоже обновлялась каждый тик, `/overview/fragment` дополнительно
+рендерит её как out-of-band swap (`hx-swap-oob`) — тот же приём, которым
+уже обновляется общий баннер ошибок (`templates/layout.html`,
+`error_banner`). При правках вёрстки `/overview` важно сохранять именно
+этот порядок и не переносить форму фильтра/панель статистики обратно
+внутрь опрашиваемого блока.
+
 ### Добавление адресов и принудительный повтор — один и тот же вызов
 
 Форма на `/ips` всегда бьёт в `POST /api/v1/admin/ips`. Поведение зависит

docs/USAGE.md

@@ -138,6 +138,10 @@ curl -s http://<control-api>:8080/api/v1/admin/ips \
   | jq '[.[] | select(.State=="done" or .State=="failed") | {IPAddress, State, OverallResult}]'
 ```
 
+В `admin-dashboard` то же самое — страница `/overview`, с поиском по IP и
+фильтром по статусу (`pass`/`partial`/`fail`/`cancelled`) над обеими
+таблицами сразу (см. [DASHBOARD.md](DASHBOARD.md)).
+
 ## Значения полей IP
 
 | Поле | Значение |
@@ -249,6 +253,9 @@ curl -s http://<control-api>:8080/api/v1/admin/registry/203.0.113.10 | python3 -
 
 В `admin-dashboard` — страницы `/registry` (список) и `/registry/{ip}`
 (история конкретного адреса), со ссылкой туда со страницы `/ips/{ip}`.
+На `/registry` — тот же поиск по IP и фильтр по статусу, что и на
+`/overview`, плюс он отражается в адресной строке (`?q=&status=`), так что
+отфильтрованную ссылку можно сохранить или переслать.
 
 **Глубина хранения.** Чтобы история не росла бесконечно на адресах,
 которые перепроверяют очень часто, можно ограничить, сколько последних