Vindicar

Какие интенты ты задаёшь боту?
Если приложить волевое усилие и открыть документацию, то можно увидеть, что для работы on_raw_reaction_add требуется интент reactions.

Выносишь цикл проверки в отдельную корутину check_loop(), в main() делаешь

async def main():
    logging.basicConfig(level=logging.INFO)
    async with ClientSession() as session:  # сессию лучше по сто раз не создавать
        check_task = asyncio.create_task(check_loop(session))  # создай её однажды и передай в check_loop
        try:
            bot = Bot(
                token='"'
            )
            await dp.start_polling(bot)
        finally:
            check_task.cancel()  # внутри check_loop() сгенерируется прерывание asyncio.CancelledError

Единственное, придётся в коде/конфиге прописать id чата, куда check_loop() будет отправлять сообщение с результатами.

Составляешь список документов в постановлениях (модуль pathlib, метод Path.glob).
Перебираешь строки csv файла (стандартный модуль csv в помощь).
Для каждого уникального ID (номера) в csv ищешь подходящее имя файла в постановлениях. Можно простым разбиением имени по символу № (смотри str.split() и str.partition()).
Определяешь желаемый путь, куда записать файл. Стандартный модуль pathlib в помощь.
Перемещаешь файл вызовом shutil.move() (стандартный модуль shutil).

itertools.product() позволит перебрать все сочетания символов. Поиграв с параметрами, можно даже задать правила вида "первый символ - согласная, второй - цифра, ..." . Но для брутфорса обычно лучше словарная атака.

Очевидно, хранить существующего бота где-то. Или в глобальной переменной, или переделать функцию в метод класса и хранить ссылку на бота в поле класса. Главное, чтобы эта ссылка была в поле видимости твоего кода.

Но я бы заметил, что слишком частое редактирование сообщения - не лучшая идея. Я бы разбил процесс на две части - обработчик обновлений от OpenAI складывает в какой-то буфер полученные части текста, а бот время от времени проверяет буфер и дописывает всё, что там лежит, в сообщение.

Не путай определение функции с её вызовом.
В твоём коде замена значения переменной происходит, когда ты вызываешь функцию, а не когда ты её определяешь.

Окей, если объяснить на пальцах, то есть два варианта.
1. Собственные знания модели. Большие языковые модели, по сути, умеют только одно: предсказывать следующее слово по набору предыдущих. Почти все остальные задачи сводятся к этому. Так что веса модели - это описание офигительно сложной функции, которая описывает взаимосвязь между предшествующим набором слов и последующим словом. Все "знания" модели, таким образом, сводятся к ответу на вопрос "какое слово будет дальше с наибольшей вероятностью?" Отсюда вытекают и слабые стороны языковых моделей - они не понимают, что пишут, они просто пишут "по аналогии".
2. Retrieval Augmented Generation. Грубо говоря, в распоряжении модели есть база текстов, где каждому фрагменту сопоставлено некоторое описание его смысла. Модель использует такое же представление смысла слов в запросе, чтобы найти подходящие по смыслу фрагменты. Найдя эти фрагменты, модель строит ответ уже на основании фрагментов И запроса. Это не требует переобучения модели для добавления новых знаний, как в первом случае. Но будут проблемы, если фрагменты слишком длинные или их слишком много.

А ты прочитай свой код внимательно.

@router.message(F.text == 'Каталог')
async def catalog(message : Message):
    categories_kb = InlineKeyboardBuilder()
    categories = db.get_group_name_from_db()
    for category in categories:
        categories_kb.add(InlineKeyboardButton(text=categories, callback_data=f'category_'))  # чему-чему равен text?
    return categories_kb.adjust(2).as_markup()  # ты же понимаешь, что строка ниже не выпонится?

    await message.answer('Выберите категорию товара:', reply_markup=await categories)  # что ещё за await? categories - это список.
    # или ты имел ввиду categories_kb?

Тебе не нужно вычитывать все данные из БД, чтобы потом искать их на питоне - задача прекрасно решается в рамках SQL запроса.
Если под "самым близким" числом ты понимаешь самое близкое по модулю, то задача звучит так: найти в таблице число, модуль разности которого с заданным числом минимален.
Например, если у нас таблица Numbers, в которой есть столбец num, содержащий искомые числа, то запрос будет иметь вид:

SELECT * FROM Numbers ORDER BY ABS(num - заданное_число) ASC LIMIT 1

Т.е. мы для все строк в Numbers рассчитываем разность между num и заданным числом, находим модуль, сортируем по возрастанию этого модуля (т.е. сортируем числа от близких к далёким), а потом берём первый (т.е. самый близкий) результат.

К своему коду адаптируешь самостоятельно.

Под какую версию aiogram код, и какая версия установлена у тебя? aiogram изменил API при переходе с версии 2 на версию 3.

select "Route_num" from "Route TB"
Во-первых, ты кавычки не перепутал? В SQL вроде имена столбцов и таблиц экранируются `бэктиками`, а не "кавычками".
Во-вторых, ты просишь выбрать одно значение на каждой строке. Но в то же время обращаешься к item[1], т.е. ко второму элементу строки. Которого быть не может, так как ты выбираешь только один.

await FileSendingGroup.next() выполняет переход на следующее состояние.
Если ты можешь понять, когда пользователь послал последний файл, выполняй этот переход только тогда.

Ну во-первых, ты вот так сходу это не реализуешь, потому что помимо вложенных словарей есть списки и другие коллекции, а также есть классы. Ты, конечно, можешь схитрить - сделать класс-прокси, который сигнализирует об изменениях при __setattr__() и __setitem()__, а также реализует вызовы __getattr__() и __getitem__() так, чтобы возвращать такой же прокси для целевого объекта.
Условно:

l = [1]
d = {'a': l}
pd = MyProxy(d)
lst = pd['a']  # на самом деле lst это MyProxy(l, owner=pd)
lst[0] = 2  # прокси-список реагирует на присваивание и оповещает владлеьца - прокси-словарь

Но и это не очень хорошо, так как в примере выше я могу изменить список через ссылку l. Не говоря уже о проблемах с проверками типов данных. Так что сложно-составные структуры персистентными сделать малореально.

Я бы сказал, вообще не очень хорошая идея реализовывать персистентность вот так.
Вариант А: делай снапшоты в фиксированные моменты времени. Если сохранение снапшота слишком долгое, сделай клон через deepcopy и сохраняй клон, пока оригинал изменяется дальше.
Вариант Б: явно сохраняй изменения, которые должны быть персистентными. Каждое в отдельности.
Вариант В: Используй память, отображаемую на диск. Тогда ОС сама будет периодически сбрасывать изменившиеся страницы памяти на диск (хотя есть метод flush()).
Но в этом случае может потребоваться изменить структуру данных, избавившись по максимуму от сложных объектов типа словарей и заменив их на простые массивы байт. Если нужны структуры, то их придётся распаковывать с помощью struct. Т.е. опять приходим к тому, что структура не должна быть сложной.

Не думаю, он создаёт дочерний процесс от ноды, но в доках не написано, что этому процессу задаются особые права - значит, права будут как у ноды.

Я бы сделал минимум три уровня защиты:
1. Полученный от пользователя скрипт выполняется не напрямую, а в скрипте-обёртке. Обёртка подписывается на события аудита Питона, и мониторит событие импорта. При попытке импорта модуля не из белого списка сигнализируем родительскому процессу и вызываем заранее сохранённую os._exit(), чтобы немедленно прибить интерпретатор. Также на обёртку можно возложить собственно прогон тестов.
2. Скрипт-обёртка должен выполняться от nobody:nobody с правами только на временную директорию, в которой лежит сам скрипт и его виртуальное окружение. Директория должна пересоздаваться заново при каждом запуске скрипта. Может иметь смысл оформить выполнение обёртки внутри chroot.
3. Выполнение должно происходить внутри контейнера, который должен перезапускаться время от времени (не обязательно при каждом запуске скрипта, можно раз в сутки или около того). Передача скрипта внутрь контейнер - через сетевой сервис, хотя можно и через примонтированную директорию. Внутри контейнера сервис сам создаёт временную директорию с окружением, переносит скрипт в эту директорию (с переименованием в заранее известное имя - user_script.py или подобное) и только тогда запускает обёртку.

В этом случае атакующему нужно будет сначала обойти аудит импортов, потом сделать эскалацию привилегий, потом выбраться из-под chroot. И даже если он закрепится в контейнере, контейнер периодически перезапускается, так что малварь будет снесена.

Учи матчасть. Всё делается одним запросом.

SELECT referal_id, COUNT(*) FROM users GROUP BY referal_id

Группировка сделает так, что для каждого referal_id будет выведена одна строка, а групповые функции посчитают некий итог для каждой группы строк с одним и тем же значением referal_id. В частности, COUNT() посчитает сколько строк в группе.