Vindicar

1. По приведённой ссылке описывается API запросов Телеграма, а не API для питон кода. Используй одну из библиотек, вроде pyTelegramBotAPI или aiogram. У первого доки получше, вроде.
2. Если используешь aiogram, то в асинхронность вникать придётся. pyTelegramBotAPI использует синхронный код. В чём-то это будет проще, в чём-то - сложнее.

В коде неправильного больше чем правильного...
1. У тебя написано, что команда должна получить два параметра - text и id. Если id она должна найти сама, то его нужно убрать из параметров купить(). id нужно получить из ctx.author.id.
2. Ты вообще пробовал обращаться к своей базе? Смотрел, что тебе возвращает fetchone()?
По твоему запросу она вернёт либо кортеж с одним значением, либо None, если не было найдено ни одной подходящей строки.
Ни то ни другое сравнивать непосредственно нельзя!
Вытащи результат в переменные, проверь на None, а потом уже сравнивай нулевые элементы.
3. Убери токен бота из тела вопроса.
4. Советую cursor создавать внутри обработчика, во избежание заморочек с одновременным использованием.
5. Советую указывать типы параметров в описании команды! discord.py обращает на них внимание, и пытается конвертировать входную строку.
async def купить(ctx, text: str):
6. Как уже было написано, execute() принимает вторым параметром КОРТЕЖ, пусть даже из одного элемента. А кортеж из одного элемента пишется как (item,).

1. Первый пользователь посылает сообщение. Запускается копия search_vk() и выполняет синхронный запрос:
user_data = vk_parser.get_user_data(user_id)
Пока запрос выполняется, бот стоит, так как код синхронный.
2. get_user_data() деляет глупости вида

with open("FIO.txt", "w") as file: #открываем один и тот же файл для любого запроса

или

global bio # используем одну и ту же переменную для любого запроса

Ну и прочие медиа-файлы тоже одни и те же для разных запросов.
3. Обработчик сообщения первого пользователя доходит до строки

loading = await message.answer('<b>Идёт поиск</b>')

Так как это await-вызов, планируется вызов корутины, и асинхронная программа переходит к следующей доступной операции, пока выполняется отправка сообщения. Собранные данные лежат в файлах.
4. Второй пользователь посылает сообщение. Запускается ещё одна копия search_vk() и тоже выполняет синхронный запрос get_user_data(). Второй вызов get_user_data() перезаписывает данные в файлах.
5. Обработчик сообщения второго пользователя доходит до строки

loading = await message.answer('<b>Идёт поиск</b>')

и засыпает, пока сообщение отправляется.
6. Тем временем сообщение первого пользователя отправилось. Обработчик получает управление, и отправляет содержимое файлов - которое было перезаписано, заодно закрывая их.
7. Сообщение второго пользователя отправилось. Его копия search_vk() пытается отправить файлы, но первый обработчик их уже закрыл.
Дело ещё осложняется сетевым лагом, так что трудно сказать, кто в итоге будет первым.

Если по прочтению ты ещё не понял, в чём дело, скажу прямо: не используй глобальные объекты, будь то файлы или переменные, в конкурентной среде! Убедись, что каждая копия обработчика запроса имеет свои хранилища для данных! Локальные переменные безопасны, они создаются каждый раз заново. Если не можешь обойтись без файлов на диске, либо используй модуль tempfile, либо привяжи их имена к ID отправителя сообщения, чтобы хотя бы разные пользователи не сталкивались лбами.

Во-первых, сама идея - плохая, так как ник можно менять. Используй числовой id пользователя вместо ника.
Во-вторых, никогда не формируй текст запроса через форматирование строк. Используй подстановку параметров.

f"SELECT id FROM userifo where id={member.id}
Никогда так не делай.
А вообще, что ты пытаешься сделать? Перебрать все сервера и занести их участников в БД?
Во-первых, у класса Client (и у его наследника discord.ext.commands.Bot) есть свойство guilds. Это список отдельных серверов, можешь просто перебрать его for'ом.
Во-вторых, в sqlite есть синтаксис INSERT ON CONFLICT UPDATE, который позволяет добавить запись или обновить её, если она уже существует, за один запрос а не за два.
В-третьих, твой алгоритм перебора не сумеет обнаружить участников, покинувших сервер, так как они просто не появятся в списке участников.
В-четвёртых, если ты не понимаешь, зачем в коде та или иная строка, тебе рано браться за написание ботов. Поучи сначала основы питона, почитай документацию на discord.py, потом вернёшься к теме. Сэкономишь много времени на вопросах.

В коде каша. С одной стороны, вроде знаешь про плейсхолдеры, но не синтаксис SQL:

cursor.execute('INSERT OR IGNORE bazaa (user_id, user_name, username) VALUES (?, ?, ?)', (user_id, user_name, username))

А в другом месте кода с точностью до наоборот.

INSERT INTO USERS (user_id, username, first_name,  last_name) VALUES ({user}, "{username}", "{first_name}", "{last_name}", "{ctime()}");

Почитай про синтаксис INSERT и ON CONFLICT и никогда не формируй запросы форматированием строк.

random.choice()

Потому что ты приказал боту сделать именно так.

await member.add_roles(muterole) # добавляешь роль
await asyncio.sleep(time * 60) # ЖДЕШЬ
await member.remove_roles(muterole) # удаляешь роль
await channel.send(embed = emb) #отправляешь сообщение

Он и делает, что сказано.

Если цикл for block in soup.find_all не выполнится ни разу (например, нет подходящих элементов), то task_stack не будет присвоено значение. А ты дальше его читаешь.
Предусмотри какое-то значение по умолчанию для этой переменной, и проверяй такой случай.

Отступы косые, будь внимательнее.
У тебя check() объявлена как локальная функция внутри __init__(), соответственно в самом классе такого метода нет. А так как метод объявлен абстрактным в BoundFilter и не переопределён в твоём классе, то и твой класс остаётся абстрактным. А потому попытка создать его экземпляр проваливается.

В обработчике команды:
1. Делаешь хранилище, словарь-dict с ключом вида (message id, user id) и значением в виде объектов asyncio.Event.
2. Когда отправляешь сообщение для реакции, помещаешь в хранилище пару (id сообщения, id адресата), а значением задаешь новый asyncio.Event().
3. С помощью asyncio.wait_for() и Event.wait() ждешь срабатываения этого объекта Event или желаемого таймаута.
4. Если объект сработал и функция wait_for() вернула значение, то реакция была. Действуешь соответственно.
5. Если wait_for() выбросила asyncio.TimeoutError, то произошел таймаут. Действуешь соответственно.
В обоих случаях удаляешь из хранилища ключ (id сообщения, id адресата)

Что касается реакции, то тебе нужно событие on_raw_reaction_add() и ассоциированный с ним объект класса RawReactionActionEvent. Оттуда можно достать сведения о пользователе, сообщении и эмодзи. Ищешь в хранилище пару (id сообщения, id пользователя), если нашел - значит, это одно из наших специальных сообщений. В обработчике этого события выбираешь соответствующей этой паре объект asyncio.Event и дергаешь его метод set(), чтобы просигналить вышеприведенному алгоритму (он тогда пойдёт по ветке 4). Иначе не делаешь ничего.

q.execute("update config set bitcoin = " + str( new_bitcoin ) + " where id = 1")

За такое надо бить по рукам. Железной линейкой. Поясню почему:
если new_bitcoin присвоить число 1234 или строку "1234", то получим запрос
update config set bitcoin = 1234 where id = 1
Этот запрос синтаксически корректен с точки зрения языка SQL.
А вот если new_bitcoin присвоить строку "foobar", получим запрос
update config set bitcoin = foobar where id = 1
С точки зрения SQL это обращение к столбцу foobar. Которого, разумеется, нету.

А теперь, внимание, вопрос: какого огурца ты не ознакомился с азами использования СУБД, а именно с синтаксисом подстановки значения?
Читай тут, начиная со слов "Instead, use the DB-API’s parameter substitution". Осознай, и больше так не делай.

Ну и до кучи: что будет, если в bitcoin будет строка вида "0; --"?
update config set bitcoin = 0; -- where id = 1
Всё, что после "--" это комментарий, и будет проигноировано. Т.е. запрос перезапишет весь столбец bitcoin нулями.