Групповое удаление бэкапов, поддержка 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/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), «Нет соединения».