rPman

Забудем что принципиально хранить пароли - плохая практика, но так как задача уже такова что хранение вынужденное то:
1. шифровать логины и пароли (весь набор данных, не имеющих смысл друг без друга, лучше хранить сериализованными в одном поле, особенно когда от задачи к задачи поля меняются, т.е. логин пароль почта api key, gpg ключи шифрования и т.п. пусть это будет свободная json строчка, за ее анализ отвечает клиентская часть приложения)
2. ключом/паролем, который не хранится в базе данных (он должен являться частью бакэнда, т.е. в том месте где на бакэнде хранятся настройки подключения к внутренним сервисам либо отдельное место хранения) - при разделении работ между людьми (обслуживать базы могут другие люди, чем те кто имеет доступ к бакэнду) чувствительные данные не утекут легко.
3. логируй все, т.е. показал пароль - сохрани в специальном логе (в базе или файлах уже вопрос организации работ) - кто, когда, с какой машины, что получил
4. когда показываешь пароль на клиентской машине, повторно запрашивай авторизацию (чтобы не использовалась автосохраненная), важный момент, это исключит кражу данных уже на стороне клиента, очень мало кто правильно организует рабочее место (это просто неудобно и дорого).

POST это http?
Тебе нужен свой http сервер, реализующий нужную логику. Инструментов миллион, попробуй swoole
.
Если его реализовать без многопоточности и асинхоронщины, то пока он будет обрабатывать один запрос, никакой другой не будет получен, другие будут ждать в очереди сетевого стека и отваливаться с ошибкой по таймауту.

Интересно что встроенный отладочный http сервер php -S xxx:port какраз однопоточный, и хотя его не рекомендуют для продакшн, можешь попробовать.

Системный rename атомарный, т.е. два одновременно работающих приложения отработают так что одно вернет true а другое false. Осторожно с сетевыми файловыми системами, к примеру nfs не гарантирует.

Но вот записи в файл - нет, совершенно нормально получить кашу, если писать в файл к примеру логи (строчки) одновременно из двух потоков/процессов. И fflush тут не спасет, понадобится синхронизация либо через блокировки файлов (не рекомендую) либо через семафоры/мьютексы или другие IPC механизмы. Есть мнение что запись кластера файловой системы - атомарна (если твои writes выровнены по нему и размером с него), но как я понимаю гарантий этого никто не дает.

p.s. если у тебя многопоточный доступ к данным, настоятельно рекомендую не извращаться а взять готовую базу данных, даже если объемные блобы будут продолжаться храниться в файлах на диске (имя в базе) а за блокировки отвечает база данных или иной механизм, проблем будет на порядок меньше.

если нужно по каждой категории - добавь к запросу group by категория, в select будет sum(сумма) и категория

если выбор критерия вычисляемый, пропиши его формулу в select сумма as field_name ... group by field_name

Это худшая задача для реляционных баз данных, что там будет происходить с foreign_key я вообще молчу, все решаемо но скорости будут не очень

Если нет связанных таблиц (что логично, твой id на самом деле не идентификатор, не вводи народ в заблуждение и назови по другому) в твоем случае скорее всего можно схитрить, можно key_id считать на лету, т.е. ключевое поле с autoincrement, но назови его по другому, например key_id_orig
1+key_id_orig-min(key_id_orig)

но это сработает только если удаление возможно только самой старой записи, если же будут удаления из середины, то порядок придется пересчитывать по другому, через сортировку всей таблицы по key_id_orig и подсчету колонок функцией row_number

удостоверься что $trainings[1] действительно содержит побайтово "pump", причем очень часто символы могут совпадать визуально но не значением, например русская 'Р' и английская 'P'.

выведи обе сравниваемые строки с помощью bin2hex