Ипатьев

Весь вопрос в требуемой точности.
Я могу написать в юзер-агенте что у меня FireChrome Opera версии 100500 для межгалактических планшетов.
А на самом деле это будет Brave для PC XT.

Однако для любых осмысленных применений точности определение вполне достаточно. Существует 100500 либ, которые выдают все требуемые характеристики по юзер-агенту.
Собственно, все сайты в интернете так и работают, в частности определяя мобильность клиента.

Немного странно спрашивать "в чем может быть проблема", если это написано прямо в заголовке вопроса.
Ошибка Permission denied является совершенно стандартной, переводится как ошибка прав доступа к файлам/папкам.
".htaccess" (как и sqlite) здесь совершенно не при чем
Пользователь, под которым выполняется веб-сервер, не имеет права на запись в папку app/static/images/goods/
Надо разобраться, под каким пользователем создана папка и под каким пользователем выполняется веб-сервер. В самом тупом случае поставить папке права 777, но лучше всего конечно сделать так, чтобы веб-сервер выполнялся от имени пользователя

Технически равноценны, но второй при сравнении с нулём выглядит глупо.
Хорошо или не хорошо - вопрос философский. РНР до сих пор язык со слабой типизацией, и никаких подвохов или расходов тут нет.
Я бы сказал, что неявное приведение к булеву типу до сих пор используется повсеместно, что в if, что в while. Особенно в последнем. Писать while (($row = $stmt->fetch()) !=== false) вместо while ($row = $stmt->fetch()) пока ещё народ отказывается.

Понятное дело что ни к посетителям, ни к сессиям мемкеш никакого отношения не имеет, как и РНР. HTTP - это stateless протокол, и все клиенты в РНР на одно лицо.
Мемкеш - это демон, который обслуживает входящие соединения, которые для него тоже все на одно лицо. Причём это лицо - РНР, а не какой-то там НТТР клиент.
РНР конечно может создать ключ в мемкеше на основе куки, полученной от пользователя, но для мемкеша это будет совершенно обычный ключ, не привязанный ни к какому "клиенту". А всё привязка - это чисто интерпретации на уровне пользовательского РНР кода.

А вот почему тормоза и дубли - тут я ответить не могу, потому что с мемкешем сталкивался лет 10 назад по касательной. Это к вопросу о том, что искать часы надо там, где потерял, а не не под фонарём потому что светлее. И задавать вопрос надо про исходную проблему, а не про свои догадки по её поводу.

По идее никаких дублей в мемкеше быть не должно - это key-value хранилище и ключи должны быть уникальными.
Возможно, выгрузка показывает уже просраченные ключи.
А тормоза, возможно, из-за того, что ключи постоянно перезаписываются, вместо того, чтобы записываться только тогда, когда надо обновить данные.

В целом мемкеш уже давно вышел из употребления, и его заменил редис

потому что переводы строк конечно же

Почему не нужно заранее объявлять массив?

Как правильно заметили в комментарии выше, "это РНР, тут так можно".
Раньше вообще можно было инициализировать переменную как строку, и потом обращаться к ней, как к массиву.
Начиная с 7 версии начался отход от таких вольностей, но он всё ещё в процессе.

Значит то что пишут $result = [] Это я удобства?

Не для "удобства", а для того, чтобы волосы на голове сохранились подольше.
В данном случае нужды в явном присвоении нет.
Но любой код со временем изменяется. И функция tower_builder() может разрастись. Там появится ещё один цикл, который работает с массивом $result. Который получит какое-то значение до начала нашего цикла, и в итоге конечный результат будет неправильным. Поэтому $result = [] перед началом работы с массивом - это не каприз или удобство, а необходимость

Потому что ./css/style.min.css - это бессмыслица и карго культ.
Ссылки на локальные ресурсы должны быть абсолютными путями от корня сайта. А не вот это вот.
То есть в данном случае надо убрать точечку.

Ну ведь всё просто же.
В отличие от файловой системы, где никогда заранее не знаешь, где у неё корень, с веб сайтом всё просто и понятно, корень всегда один - /
/ - корень сайта
/css - папочка css в корне сайта
/css/style.min.css - файл style.min.css в папочке css которая лежит в корне сайта
Всё просто, понятно, очевидно

Зачем вообще было писать эти точечки?
Они начинаются, когда ты только учишься склыдывать а и б в HTML. И нет у тебя никакого веб-сервера, а есть файлик на диске. В этом случае да - без относительных путей никак не обойтись
Но как только начинается РНР, который без веб сервера уже не работает, про все точечки в локальных ресурсах надо забыть, и писать всегда абсолютные пути от корня сайта.

Во-первых, зачем тут первый запрос?
Во-вторых, кроме количества совпадений надо наверное запрашивать и сам id? Ну по логике? если мы хотим вывести id, то надо наверное это поле указать в SELECT?
В-третьих, надо добавить группировку, GROUP BY
В-четвёртых, если надо вывести любые значения из первой, а не только те, у которых есть записи во второй, то нужен LEFT JOIN

• Инкапсуляция - это самое простое. В объекте лежат данные и методы для работы с ними (причём данными могут быть и другие объекты. см. Композиция). Самое главное в инкапсуляции - не переборщить. Инкапсулировать только то, что относится одной конкретной задаче. Всё остальное делегировать другим объектам (см. Композиция).
  
• Наследование - это тоже самое простое и самое опасное. Захотел добавить новый функционал к уже существующему классу - унаследовался, дописал методик - и в путь! А потом исходный класс поменяли, и он стал ломать поведение унаследованного. Лучше всего взять себе за правило наследоваться только от абстрактных классов. А поведение менять с помощью свойств-объектов других классов (см. Композиция).
  
• Полиморфизм. Один метод - поведение разное. Проще всего достигается за счёт использования свойств-объектов других классов (см. Композиция).
  
• Композиция - это самое интересное. Объект действует не сам по себе, а с помощью свойств-объектов, которые передаются в конструктор при создании объекта. Например, у нас есть класс Модели, который должен уметь делать КРУД. А точнее сам по себе он содержит только данные, а в качестве зависимости в него передаётся объект для работы с БД, имеющий собственно эти самые методы create(), read(), update() и delete(). И вот этот объект может быть как инстансом класса, работающего, например, с Mysql, а может быть - работающего с Редисом. И теперь, в зависимости от наших потребностей, одна и та же модель может сохраняться как в Редис, так и в РСУБД. Без изменения и единственной строчки кода!
  

В общем случае (а особенно - начинающим) ничего сохранять в таблице USERS не нужно.
А "чтобы передать апишки и так далее" надо просто запросить эти бонусы из таблицы бонусов, просуммировать, и передать куда надо.

Как правильно заметили выше, неопределенный по размеру массив данных в БД - это таблица.

Для сферического обновления в вакууме не нужно вообще ничего.
БД спокойно по умолчанию пишет десятки тысяч строк в секунду.
То есть просто записывать и всё.

При возникновении конкретных проблем надо собраться с мыслями и задать конкретный вопрос, детально описывая проблему. А не вот это вот "ну у нас там много всего и растёт нагрузка".

В качестве чисто гадательной рекомендации поиграться с innodb_flush_log_at_trx_commit / транзакции.