Александр Нестеров

Почему не подгружаются статические файлы в режиме разработки?

Потому-что у джанги нужно отдельно обрабатывать пути до статики в dev-режиме
(вообще странно, что вы добрались до докера и прода, но не знаете про такие базовые вещи)
upd.
Для задания путей во время разработки нужно указывать:

STATICFILES_DIRS = [
    BASE_DIR / 'static'
]

Именно из папок, указанных здесь, будет подтягиваться статика.
STATIC_ROOT = BASE_DIR / 'static'
Указывает, куда собрать все файлы из папок, заданных в STATICFILES_DIRS.

from django.hhtp import HttpResponse

У вас ошибка в импорте

Все подключено вроде верно

Нет, не верно. Как минимум в документации описывается иной способ подключения статических файлов.
Кроме того - там описаны дополнительные шаги, которые нужно сделать, если вы только разрабатываете проект и сайт запускается через manage.py

если к примеру в корзине 2 товара, то и сообщения 2, а такого быть не должно.

Почему, собственно, не должно? Вы сами проходитесь по объекту корзины и при каждой итерации вызываете sendMessageTg

for item in cart:
                ...
                sendMessageTg(order_item)

Хотите, чтобы было одно сообщение - вызывайте один раз, передавая, например, всю корзину. Ну и измените код функции так, чтобы она работала не с отдельным заказом, а со всеми в корзине.

Это WYSIWYG-редакторы. Поиск по названию и ключевым словам должен выдать кучу вариантов. Плюс для django даже есть в виде python-библиотеки.

Ну, знать определенно обязан. Чтобы можно было продуктивно общаться с разработчиками фронта и хотя-бы в общих чертах понимать особенности формирования верстки.
Насколько глубоко - зависит от компании, в которой вы будете работать. Где-то фронт будут писать на JS фреймворках и с html вы связываться не будете, где-то будут использовать шаблоны django и весьма вероятна ситуация, когда верстальщик сделает шаблон, но заполнять его данными придется вам.

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

Вынесите форму на отдельную страницу а на старой оставьте только "вывод" данных.

Скиньте просто script я попробую разобраться

Не думаю, что здесь будет кто-то, кто будет именно писать за вас.

В общем случае:

• Вешаете на нужный элемент формы обработчик событий.
  
• По срабатыванию создаете html-запрос на нужный url (с помощью xmlhttprequest или fetch)
  
• Получаете ответ
  
• Выводите данные на страницу
  

Вам же написали - нет модуля PIL.
В чем проблема установить его?

Для начала встречный вопрос: вместо готовых решений (Стандартный токен или JWT) использовать для авторизации в DRF сессии с самописными проверками - обоснованный шаг?
Касательно вопроса - давайте подумаем логически:

The view api.views.game.view didn't return an HttpResponse object. It returned None instead.

Здесь четко сказано, что вьюха ничего не вернула, хотя должна была вернуть HttpResponse. Оригинальная вьюха возвращает Response. Далее вопрос "на подумать": что возвращает декоратор, если не падет с исключением?
---

Видел еще вот такой подход, но для меня он тоже не работает:

"Не работает" - офигенное определение. Ну так почините.