приоритет стал исполнимым: move без --section и тексты, догнавшие правило 4

Механизм расстановки приоритета не запускался ни разу: --section у move был
обязательным, а все три места, где груминг его предписывает, дают команду без
него — usage error. Чиню скриптом, а не текстами: перестановка внутри секции —
самая частая операция груминга, и требовать повторить текущую секцию значит
приглашать указать не ту.

- move: --section необязателен, без него берётся секция из индекса; сообщение
  различает перестановку и перенос
- докстринги, отрицавшие правило 4 («в беклоге порядок значения не имеет»),
  приведены к действительности
- reopen ставил возвращённую строку после сырья и давал ошибку check на ровном
  месте
- edit портил написание секции в мете; корень шире — брался нижний регистр из
  разбора, а не написание заголовка. То же в close и reopen
- дыра гейта: между заведением и ready запись не судил никто. Своя строка
  здоровья check, отдельная от «готово к взятию» — она про другое
- шесть файлов и два устава обещали, что схему типа проверяет check
- раздел from-review о серьёзности стоял на «приоритетов нет»
- остатки спринта и сессии в семи местах, включая description агента формы
- индексов два, а не три; два определения порога готовности после adopt

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

av-dev-tasks/skills/tasks/references/task-chore.md

@@ -48,13 +48,13 @@
 5. **Проверить, что это не «заодно».** Обслуживание любит склеиваться в пачку
    («обновить зависимости и переписать сборку и убрать мёртвый код»). Не
    мерджится порознь — это несколько задач ([split.md](split.md)).
-6. **Цель не проставлять.** `chore` служит работоспособности, а не направлению,
-   работоспособности, а не направлению. Работа по сопровождению проекта
-   при этом видна в роадмапе — секцией `Сопровождение`, но целью не становится.
+6. **Цель не проставлять.** `chore` служит работоспособности, а не направлению.
+   Работа по сопровождению проекта при этом видна в роадмапе — секцией
+   `Сопровождение`, но целью не становится.
 
 ## Что видит машина, а что человек
 
-`check` и `ready` смотрят на **наличие непустого** `Затрагивает` и на
+`ready` смотрит на **наличие непустого** `Затрагивает` и на
 **число** критериев — ровно то же, что у `feature`. Разница между типами здесь не
 в строгости проверки, а в том, **кому адресован ответ** на «что станет
 наблюдаемо иначе», — и это судит человек.