Групповое удаление бэкапов, поддержка CHR, строгое сравнение версий ROS

Групповое удаление бэкапов (docs/changes/013):
- страница «Резервные копии»: чекбоксы, «выбрать все», панель «Выбрано: N /
  Удалить / Снять выбор» вместо фильтров, подтверждение, итог удаления;
- backups.delete_many: все ключи проверяются до удаления, удаление параллельное;
  UI POST /backups/delete-many, API POST /api/v1/backups/delete;
- выбор строк в app.js обобщён (data-select) для устройств и бэкапов.

Поддержка CHR (docs/changes/014):
- у CHR нет /system/routerboard (HTTP 400): устройство больше не считается
  недоступным, версия FW не показывается, обновление FW пропускается;
- «есть обновление ROS» определяется строгим сравнением версий (на канале
  long-term последняя версия может быть старше установленной);
- в таблице указана причина недоступности: авторизация / ошибка ответа /
  нет соединения.

Тесты: 11 из 11.

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

docs/changes/013-bulk-delete-backups/plan.md

@@ -0,0 +1,8 @@
+# План: 013 — выбор файлов и групповое удаление бэкапов
+
+Запрос: комментарий владельца к листу «Резервные копии» в макете — «добавить селектор через checkbox и кнопку для операции группового удаления».
+Решение (макет и приложение одинаково):
+- Колонка чекбоксов и «выбрать все» в таблице файлов; при выборе полоса фильтров заменяется панелью «Выбрано: N · Удалить · Снять выбор» (тот же приём, что на странице устройств; логика выбора общая — `input[data-select]` в `app.js`).
+- «Удалить» — с подтверждением и числом файлов; после удаления возврат на страницу с теми же фильтрами и итогом («Удалено файлов: N; не удалось: M»).
+- Сервер: `backups.delete_many` — все ключи проверяются до начала удаления (чужой ключ или >500 файлов — ошибка, ничего не удаляется), удаление параллельное (8), сбой одного файла не останавливает остальные. UI: `POST /backups/delete-many`; API: `POST /api/v1/backups/delete` `{"keys": [...]}` → `{"deleted": N, "failed": M}`.
+- Макет: лист «Резервные копии» обновлён, добавлен лист «выбраны файлы, групповое удаление».

docs/changes/013-bulk-delete-backups/summary.md

@@ -0,0 +1,15 @@
+# Итоги: 013 — групповое удаление бэкапов
+
+## Сделано
+- Макет (версия 6): колонка чекбоксов и новый лист с панелью группового удаления.
+- Приложение: выбор строк, панель «Удалить / Снять выбор», подтверждение с числом файлов, итог на странице, сохранение фильтров при возврате; иконка «корзина».
+- Сервис `backups.delete_many`, маршрут `/backups/delete-many`, API `POST /api/v1/backups/delete`.
+- Логика выбора строк в `app.js` обобщена (`data-select`): работает и на устройствах, и на бэкапах.
+
+## Проверено
+- `pytest`: 10 из 10 (новый тест: чужой ключ отклоняет всю операцию и ничего не удаляет; допустимые удаляются; редирект с фильтрами и итогом; API).
+- В браузере на реальном бакете с тремя собственными тестовыми файлами (`backups/qa-bulk/…`): выбор двух → панель вместо фильтров, подтверждение «(2)», итог «Удалено файлов: 2», фильтр сохранён; «выбрать все» → «Удалено файлов: 1»; ошибок JS нет. Тестовые файлы удалены, файлы `MSK_Home` и `OZ_Dacha` не тронуты.
+
+## Замечания
+- Удаление необратимо (версионирование бакета не используется приложением) — поэтому подтверждение и ограничение префиксом `backups/`.
+- Единичное удаление из меню строки «⋯» сохранено.

docs/changes/014-chr-support/plan.md

@@ -0,0 +1,5 @@
+# План: 014 — поддержка CHR и строгое сравнение версий ROS
+
+Проблема: два новых устройства (CHR в Yandex Cloud и OpenStack) помечались offline, хотя ping, трассировка и авторизация проходили.
+Причина: на CHR нет раздела `/system/routerboard` — REST отвечает `HTTP 400 no such command or directory (routerboard)`, а `get_status` считал это сбоем устройства.
+Решение: `ros/operations.py::get_routerboard` — отсутствие раздела (400 + «no such command») означает «нет RouterBOARD firmware», не ошибку; используется в статусе и обновлении FW. Второе: на канале `long-term` «последняя» версия (7.23.7) старше установленной (7.24), а сравнение «версии отличаются» показало бы это как обновление — введено строгое сравнение `version_newer` (учитывает alpha/beta/rc). Ещё: в таблице причина недоступности различается — «Ошибка авторизации» (401), «Устройство ответило ошибкой» (другие HTTP), «Нет соединения».

docs/changes/014-chr-support/summary.md

@@ -0,0 +1,6 @@
+# Итоги: 014 — поддержка CHR
+
+- CHR и другие устройства без `/system/routerboard` опрашиваются нормально: модель — из `board-name`, FW — «—», обновление FW пропускается с пояснением.
+- «Есть обновление ROS» определяется строго (`version_newer`): версия на канале должна быть новее установленной; `7.25rc1` < `7.25`. Затрагивает бейдж Upgrade ROS, фильтр «Есть обновление» и кнопку обновления ROS («Обновление не требуется»).
+- В таблице для недоступного устройства указывается причина: авторизация / ошибка ответа / нет соединения (полный текст — в подсказке).
+- Проверено: `pytest` 11 из 11 (новый тест CHR и сравнения версий); на `Yandex-Gate` и `Warsaw-Gate` статус читается (CHR, ROS 7.24, канал long-term), оба online.