metallix

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

Можно просто выключить адблок и увидеть ответ

Закрывают эндпоинты редактирования тем же middleware с проверкой авторизации, что и админку. Используют gates и policies. Читают документацию.

Это профанация.

1. stage - это по определению не для новой функциональности, а для стабилизации уже реализованной (посмотрите перевод термина). Вы либо перепутали, либо кто-то что-то не понимает.
2. нет никакого смысла в параллельных спринтах, поскольку цель спринта - поставить работающий продукт. У вас два разных продукта в рамках одной кодовой базы?
3. бывает так, что нужно фиксить баги текущего релиза и делать фичи в новом. Если багов не много, то есть подходящий для этого процесс под названием Скрамбан. Если багов много, то нужно остановиться плодить баги, все почистить и потом перейти к Скрамбан.

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

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

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

Уже имея опыт работы с базой (так как вы писали модуль регистрации), вы, формально, можете поковыряться и сделать возможность добавлять в базу новости на сайт, а потом их выводить на этом же сайте. И внезапно, вы уже понимаете как реализовать кривой-косой блог.

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

P.S. Как говорилось людьми выше, есть такой инструмент как "поиск гугл", на худой конец "товаращи по цеху" помогут.

$pdostmt->fetchAll(PDO::FETCH_KEY_PAIR);
Первое поле результата будет ключом массива, второе - значением.

Самое правильное решение - указать в ChatMessage, что эта модель touches Chat и сортировать чаты по updated_at.

Если ваши чаты можно как-то редактировать (т.е. updated_at зависит не только от сообщений), то можно завести дополнительную колонку для Chat и обновлять её при каждом сообщении.

Всё это будет намного проще, чем джойнить сообщения и получать дату последнего.

csrf токет по идее должен быть всегда уникальный (по крайней мере в рамках одной сессии) , судя по тому что у формы на onsubmit стоит "return false;", то могу предположить что форма отправляется через ajax, проверьте отправляется ли csrf-токен.
Форма отправляется на тот же сайт?
Или вы пытаетесь отправлять с локалки на хостинг форму? если так, то конечно будет 419, для этого и придуман csrf.