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/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=`), так что
+отфильтрованную ссылку можно сохранить или переслать.
 
 **Глубина хранения.** Чтобы история не росла бесконечно на адресах,
 которые перепроверяют очень часто, можно ограничить, сколько последних