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

Вообще, требуемое, на мой взгляд, лучше реализовать через расширение модели User.
В интернете полно примеров.

А разве у вас "категория" - текстовое поле или все-таки внешний ключ?

Если коротко: не стоит так делать.

Документацию по django/postgresql

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

Через отдельную связь M:M c unicue together на внешних ключах в промежуточной таблице.
(У поля есть метод through)
p.s. Вас в этом поле ничего не смущает?

user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='topic_bookmark')

Как отобразить список избранных topic

Делать выборку не по id топика

И как их удалить

Так как описано в документации

1)Откуда берется информация в home.html в переменной post_list?

Почему вы уверены, что она там должна браться? В документации к ListView используется другое ключевое слово.
Если вы учитесь по роликам/статьям - задавайте вопрос автору/проверяйте правильно ли передрали код/убедитесь, что материал не слишком устаревший.
Ну и вы уверены, что в базе есть нужные данные?

1.Сигналы
2.Переопределите метод save.
Но прежде чем делать это учтите что сейчас это, уж извините, это ужас а не структура данных.

В качестве пользователя использую стандартного джангового юзера

Да? Ну и где это отображено в моделях? Сейчас я вижу, что для каждой игры может быть выставлена только одна оценка и средняя всегда будет равна ей. При этом с юзером эта оценка никак не связана. При этом - достаточно удалить это оценку и запись об игре тоже удалиться.
Далее - документация не рекомендует переопределять конструктор.
Допустим, вы это знаете, но решили, что так будет правильнее, ибо это именно что рекомендация. Но далее вопрос: вам не приходило в голову, что у модели уже есть какая-то важная логика в конструкторе?
Следующий вопрос: почему вы уверены что данные, передаваемые через параметры функции будут актуальнее, чем полученные путем выборки из базы.

Обычно минимально-рабочая схема следующая:
Товар: описание конкретного товара (цена, характеристики и прочее)
Заказ: Описание заказа как такового - дата-время/покупатель/статус/возможно - общая цена.
Список товаров в заказе: в минимальном наборе - внешние ключи к товару/заказу и количество.

"Корзина" может быть реализована 2-мя путями (минимум):
Прямо в таблице заказов. При этом такой заказ будет помечен статусом по типу "оформляется" и будет ограничение "1 юзер (кассир?) - 1 оформляющийся заказ"
С помощью сессии

Можно хоть в консоли (а если конкретно - в редакторах vim/neovim), хоть в блокноте.
Про версия просто позволяет ускорить создание нового проекта (сама активирует окружение, скачивает нужные библиотеки и создает новый шаблон), имеет автокомплит специфических для джанго вещей, а так-же имеет поддержку синтаксиса js/html.
Собственно, из-за первых двух пунктов, использовать про версию как раз не рекомендуется - чтобы вы в первую очередь полагались не на умную программу а на свои знания.

Написать свою форму.
С нуля или наследоваться от базовой.

blog.views.py в упор не видит импорт модели из followers

Структуру мы должны угадывать? Проверьте, что приложения находятся на одном уровне, они созданы корректно (есть init.py) и они подключены в настройках.

TypeError: __str__ returned non-string (type User)"

Код str мы тоже угадывать должны?
Предположу, что вы просто указываете что-то вроде:
return self.user
Вместо этого нужно указывать что-то вроде
return self.user.username

В теории, конечно, можно, но в 99% это будет нарушением первой нормальной формы.
Стоит отметить, что есть nosql базы данных, по типу mongodb, в которых данные "хранятся в json" (не в прямом смысле), но django не заточено для работы с ними.

Тут куда важнее связи между моделями.
Необходимо, чтобы соответствующие таблицы были связаны внешним ключом.
Например, в таблице "район" должен быть внешний ключ к "город". В таком случае - реализовать это будет довольно просто:
ключевое поле загружаете как угодно и вешаете на него событие "изменение", вызывающее js-запрос к серверу (fetch/xmlhttprequest), который будет посылать выбранные значения и на основе полученного результата формировать пункты для select`а.
Для этого, разумеется, нужно будет создать отдельное представление, отдающее нужные данные (в виде json`а, например).
Ну и не забывайте о всяких "декоративных" моментах по типу отключения второго поля пока в первом ничего не выбрано.

Читайте документацию. Там указано, как суммировать данные

Любой WYSIWYG-редактор, например Ckeditor.
Из коробки покрывает большинство требований
(Нет алгоритмов и неуверен насчет заливки - давно использовал)
Впрочем, есть поддержка плагинов