Какие вообще шаги отделяют игрока от игры?
Вот прям чтоб с чистого листа, скажем, приспичило свинтить и потестировать летающий аналог Экзорциста в NebuLeet. Да-да, с музыкой, там завезли процедурную музыку (и цветомузыку!) для программируемых кораблей.
А, перефразируя нашего обожаемого Крига, "мой жёсткий диск пуст и мой разум полон сала".

Я всё ещё топлю за самодостаточную портативную версию.
КАК она попала к пользователю и в каком состоянии - пока не важно. Да и, наверное, совсем не важно.
Первый или не первый это запуск омнилаунчера - де факто тоже.
Аксиома #1: мы не доверяем окружению пользователя и по возможности проверяем возможность операции перед попыткой записи пользовательских данных.

Запуск

1. "Потрогать" себя, чтобы проверить доступы к (здесь и далее - собственной) папке. Да, есть в Линуксе такая интересная команда - "потрогать".
2. Если нет баз данных - создать, проверить доступность на чтение и запись.
3. Если нет файла с константами - создать, проверить доступность на чтение и запись.
4. Если в БД есть пользовательские данные о лаунчерах (хоть у одной УСТАНОВЛЕННОЙ игры в БД лаунчер не local) - по-черновому проверить наличие, доступность и потенциальную работоспособность каждого используемого установленными играми лаунчера (к сожалению, в каждом случае это отдельная банка с червями).
5. Собрать в кэш предварительные статусы лаунчеров для последующего использования в элементах навигации.
6. Если в БД есть пользовательские данные об играх - забрать из БД в кэш данные о количестве по категориям (ВКЛЮЧАЯ используемый лаунчер), для указания в элементах навигации. Отдельно установленных, отдельно доступных.
7. Если всё в порядке, дать отмашку на рендеринг UI омнилаунчера.
Всё, стартовый поток окончен, дальше только реакция на действия пользователя в интерфейсе и/или попытку завершения процесса.
И для того, чтобы в UI кнопки потеребонькать, каждый раз у БД переспрашивать не нужно, можно взять заранее посчитанные цифры из кэша.

Вопрос #1: где хранить кэш (и так ли он необходим)? В оперативе?
На данном этапе, при условной библиотеке в 1000 игр на 5 лаунчерах, в кэше будет что-то типа таблицы (id,status,available,installed):
steam,installed,800,43
action,null,100,8
egs,authentificated,40,4
local,always,2,2
wine,unavailable,0,1
Я не вижу смысла в этом контексте делать какого-то различия в краткосрочном хранении данных между лаунчерами, жанрами и какими бы то ни было ещё признаками.
Потребитель у них один - рендер+механ фильтрования библиотеки игр. И сценарий использования у них в целом один. Всё равно для "чувствительных" операций (типа установки игры или авторизации в лаунчере) НАДО запрашивать БД, а не кэш...
Дёргать фильтрование пользователи могут часто - но, за исключением первых нескольких запусков после установки "с нуля", значительных изменений в этих данных не будет / будет не часто.
И где эту таблицу держать... важно ли, кстати, это?

1000 Х 5 = всего-то пять тысяч строк (при условии, что в каждой ячейке уникальное значение, это важное допущение) в основной таблице БД.
Я пока не думаю, что на таких объёмах есть резон колхозить отдельную таблицу в кэше для рендеринга UI.
Хотя привычка думать - осталась.

Думать о кэшировании при разработке, за ужином и во время просмотра эротических снов - хорошая привычка для удивительного мира хайлоада.
А какой к чертям собачьим хайлоад для всего 5к строк в единственной БД?
Если в числе пользователей (если пользователи вообще появятся) обнаружится легендарный мутант с 41k игр, ему, наверное, омнилаунчер не нужен.

Что у этого дендромутанта вообще в списке игр? А, чёрт, статистика по игровому времени у него, конечно, скрыта.
А вот у следующего по количеству игр - не скрыта...
3,3 часа на игру. Бот какой-то.
Короче, таким вряд ли омнилаунчер нужен, им уже есть где поразвлечься (и кому полоскать мозги).

Если при тестировании вскроется необходимость что-то кэшировать - будем посмотреть.

Таким образом, перед стадией прототипа поток Запуска ужимается до степени "чисто создать свои служебные файлы (если необходимо) и проверить наличие прав на чтение/запись к ним".

А старые привычки мои всегда думать о последствиях "на максималках", наверное, стоит всё-таки отправить в мусорку.
Не надо это никому в 2026 году.
Особенно для сраной таблицы на сраных 5к строк в пике.