Владимир Летягин

На самом деле 100% uptime не сможет обеспечить никто.
Наиболее приближенным вариантом может быть такая схема:
round robin dns c ip адресами маршрутизаторов, которые обеспечивают доступ к базе данных
+ два запущенных инстанса базы данных в разных дата центрах с репликацией, когда база данных в одном дц является мастером, а вторая слейвом. При падении мастера назначать мастером слейв, а маршрутизаторы должны направлять запросы к новому мастеру.
Но это достаточно дорого и не думаю что необходимо, если у вас не что-то вроде банковского процессинга. Хотя даже товарищи вроде тинькова и сбера временами падают.
Так что самым правдивым ответом на вопрос "Как сделать так, чтобы mysql сервер был запушен всегда" ответ будет - "никак" :)

С натяжкой можно назвать решением https://instantcms.ru/
Достаточно интересное решение, где у пользователей есть свои страницы, возможность вести блоги, постить фотки и т.п.

Ты немного перепутал логику подгрузки содержимого.
В layout.blade.php нужно
@yield('header')

А в index.blade.php

@extends('layout')
@section('header')
Содержимое header'a
@endsection

Лучше разобраться в этом поможет это

Вообще все варианты так себе :)
В мире пхп принят такой стиль

if ($expr1) {
    // if body
} elseif ($expr2) {
    // elseif body
} else {
    // else body;
}

Независимо от количества строк в теле.

Подробнее можно почитать здесь, а конкретно насчет if здесь

Большая часть разработчиков старается придерживаться именно рекомендаций в PSR

SELECT users.*, const.name FROM users
LEFT JOIN const ON users.const_id = const.id

Ну и можно не забывать, что полям можно давать свои имена

SELECT users.*, const.name const_name FROM users

Примерно так

RewriteEngine On
RewriteRule ^/css/main\.css$ /css/main.css?v=0.5 [L]

Или так для всех css файлов

RewriteEngine On
RewriteRule ^([a-z0-9]+\.css)$ /css/$1?v=0.5 [L]

Первым делом я бы протестировал на другом сервере, а действительно ли будет забанен ip при большом кол-ве запросов. Такое встречается не так уж и часто.
Подмена user-agent вряд ли поможет.
Остается два варианта - или ограничить частоту запросов (Например 1 в секунду) или через прокси.
Как вариант сделать так - имеем массив с прокси и или достаем информацию через них подключаясь к ним по очереди, или достаем информацию асинхронно, где каждый запрос на отдельном прокси имеет паузу в пару секунд.

Здесь уже больше зависит от твоих потребностей.
Обычно делают два отдельных git репозитория для фронта и бека.
Так ты всегда сможешь отдельно откатывать изменения для них.

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

Если я правильно понял твои потребности, то тебе не стоит сильно над этим заморачиваться, а просто начать использовать. И со временем придет понимание того, что именно нужно.
Главное не забудь хранить все на чем-то вроде битбакета.

И да, чтобы не делать бекап структуры базы используй миграции, если еще не используешь их.

В комментариях увидел, что интересует процедурный стиль.
Помнится очень давно, интереса ради, делал роутинг на switch case
Нечто похожее на это

$uri ='/news/35';

switch ($uri) {
    case (preg_match('/\/news\/\d/i', $uri) ? true : false):
        //include news file
        break;
    default:
        //404
}

Но все таки лучшим вариантом будет сделать массив с нужными роутами с дальнейшей проверкой на соответствие и прогрузкой файла с нужным кодом