vreitech

SET track_activities = off;, как и другие SET-команды, позволяющие менять параметры без перезапуска, работает только в пределах сессии.
Для смены в пределах кластера следует пользоваться ALTER SYSTEM SET: https://postgrespro.ru/docs/postgresql/17/sql-alte...
Например:
ALTER SYSTEM SET track_activities = off;
Поскольку этот параметр можно менять без перезапуска PostgreSQL, далее для применения должно быть достаточно выполнить SELECT pg_reload_conf();
Будете проверять с помощью SHOW track_activities; - не забудьте перезайти в psql.

Если при выполнении через docker/podman команды в контейнере (параметр exec) предполагается, что потребуется пользовательский ввод (т. е., как в вопросе выше, не только запустить psql, но и вводить команды для него), то важно не забывать про параметр -i docker/podman, который и обеспечивает работу ввода (передачу команд с клавиатуры запущенной через exec в контейнере программе).
Обеспечиваемый параметром -i функционал не "бесплатен" (требует ресурсов системы и подвержен блокировкам либо является их источником), именно поэтому он вынесен в отдельный параметр, что позволяет для программ, требующим пользовательского ввода (или, правильнее сказать, ввода через stdin), предоставить его, задействовав соответствующие ресурсы и механизмы; при запуске программ, не требующих такового ввода, в свою очередь, опустив параметр -i, можно исключить их блокирование по вводу через stdin (возможно ошибочному или непреднамеренному), не выделять на обработку ввода ресурсы.

это в общем случае определяется параметром max_connections.
в случае, если количество подключений к серверу достигло данного максимума, то в новых подключениях будет отказано, пока не освободится одно из занятых подключений.
если подключение установлено, то по нему может быть передан на выполнение запрос. он начнёт выполняться и, в зависимости от настроек таймаутов, от того, какие блокировки и на какие объекты имеются в СУБД и какой уровень изоляции используется, запрос либо выполнится; либо выполнится частично и встанет в ожидание освобождения какой-то из блокировок, и после освобождения продолжит выполняться; либо подождёт освобождения блокировки и прервётся по таймауту (результат такого частичного выполнения откатится); либо выполнится частично и прервётся по нарушению сериализации (результат такого частичного выполнения откатится).
вроде ничего не забыл.

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

Один из самых годных ресурсов - документация. В частности, разделы про подключение и аутентификацию:
https://postgrespro.ru/docs/postgresql/16/runtime-...
https://postgrespro.ru/docs/postgresql/16/client-a...

PostgreSQL на сервере уже установил, даже создал БД, но подключить не получилось к боту.

Вам следует привести получаемое сообщение об ошибке в таком случае.
И я бы ещё рекомендовал попробовать попробовать подключиться с помощью клиента psql (он у вас уже установлен, коль вы поставили сервер postgresql) и добавить сюда и его сообщение об ошибке, поскольку с трейсами питона обычно разбираться мало кому охота (не говоря уже о том, что в них не всегда есть что-то внятное по проблеме подключения).

Вы пишите, что настройки в .env-файле у вас стандартные. Вместе с тем у вас в .env задан пароль пользователя postgres, а в стандартной поставке postgresql в Linux у пользователя postgres пароля нет (и подключения под этим пользователем принимаются только с local-авторизацией на unix-сокет, по TCP/IP вы не подключитесь).
Так что в вашем случае я бы сначала через sudo залогинился под root, через su переключился на пользователя ОС postgres, подключился к СУБД из терминала с помощью psql, создал нового пользователя СУБД, затем назначил бы ему пароль, а уже эти логин и пароль нового пользователя использовал бы в .env.
https://postgrespro.ru/docs/postgresql/16/sql-crea...

задать - можно. использовать в этом же селекте в where - нет.

в PostgreSQL строка типа jsonb будет хранить ключи, отсортированные в лексикографическом порядке, что вы и демонстрируете.
если хотите сохранить порядок, который был при вставке - используйте тип json. но в этом случае формат хранения отличен от jsonb (по факту более приближен к text, насколько я знаю), и для операций, доступных только для jsonb (если таковые есть) придётся кастовать json в jsonb.

alter role username set idle_in_transaction_session_timeout = '1000min';

вестимо.
возможно потребуется этим пользователем переподключиться, к сожалению, не в курсе, применяется ли это к уже имеющимся сессиям на стороне PostgreSQL.

postgresql хранит базу данных не в одном файле, а во множестве файлов в разветвлённой группе каталогов. данный каталог задаётся при запуске сервера postgresql, и он не должен размещаться в каталогах каких-либо других программ, проектов и т. п. (вплоть до того, что доступ на корневой каталог данных БД выдаётся только пользователю и группе postgres). ну т. е. если вы установили сервер postgresql, то файл базы данных есть, и не один, просто в том месте, где должен быть, а не в том, в котором вам кажется уместным. =)
подключение к БД происходит либо по протоколу TCP, либо через unix-сокет, а не через какой-то файл базы данных. как именно это правильно делать - читайте документацию к вашему фреймворку по работе с postgresql.

я не понял, что имеется ввиду под дозаписью колонки в существующую структуру. если колонка создаётся без указания default-значения, то перезаписи строк в таблице не происходит, меняется лишь заголовочная часть (в которую добавляется информация о новой колонке) и битовая карта null'ов (относительно дешёвая операция). если колонка создаётся с указанием default-значения, то происходит пересоздание (удаление и новая вставка) всех строк в таблице с добавлением нового поля с default-значением (со всеми вытекающими в виде сбросов грязных страниц на диск, частичным вымыванием кеша, генерацией WAL, запусками автовакуума). индексы при этом также перезаписываются в моменты проходов автовакуума (при вычищении мёртвых версий строк указатели в индексах меняются на актуальные версии строк).

я хочу изменить данные напрямую в таблице, а не языком sql

напрямую в таблице данные меняются шестнадцатиричным редактором (не забывая про остановку сервера ostgres, контрольные суммы, если включены, и журнал предзаписи). при изменении данных через pgadmin4 они меняются не напрямую, под капотом там всё-равно SQL-запрос.

Скорее всего проблема в этих замочках

насколько я знаю, pgadmin4 не даст менять таблицу, если в ней отсутствует хотя бы один столбец, для которого указан первичный ключ, он же PRIMARY KEY. если структура и назначение вашей таблицы позволяют - сделайте первичный ключ по какому-либо из полей, хотя бы по тому же id, на первый взгляд он для этого у вас подходит.