Survive revoice's ffmpeg teardown and explain failed deletions

Switching tracks killed the process: revoice's #cleanUp() dereferences
this.fProc unconditionally, and its own ffmpeg error handler calls stop()
a second time after stop() has already nulled that field. Killing ffmpeg
is what triggers that error, so its handlers are detached first, the
instance's stop() is wrapped defensively (revoice calls it internally),
and an uncaughtException handler keeps the bot in the channel if the
dependency throws from another async callback.

Failed command-message deletions were logged at debug, i.e. invisible in
the default configuration; they now warn with Stoat's error type, and the
README says which permission the bot's role needs.

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

README.md

@@ -178,8 +178,9 @@ cd /opt/stoat-mbot && docker compose up -d --build && docker compose logs -f
 Все параметры — в [.env.example](.env.example). Что стоит знать:
 
 - `DELETE_COMMAND_MESSAGES=true` (по умолчанию) — бот удаляет сообщение с командой, чтобы не
-  засорять канал. Нужно право `ManageMessages`; без него команда всё равно отработает,
-  а неудачное удаление уйдёт в лог на уровне `debug`.
+  засорять канал. Для этого роли бота нужно право **Manage Messages** в настройках сервера
+  (Settings → Roles → роль бота) или в правах самого канала. Без него команда всё равно
+  отработает, а в логе будет `could not delete command message` с причиной отказа.
 - `REQUIRE_DJ_ROLE=true` — управлять смогут только владелец сервера, обладатели `ManageServer`
   и роли из `DJ_ROLE_NAME`. По умолчанию `false`: играть может любой участник сервера.
 - `IDLE_TIMEOUT_SECONDS` — через сколько секунд простоя (или пустого канала) бот выходит из войса.