Arturbalagur

Чтобы понять принципы ООП, книги не требуются. Взгляните вокруг себя. Всмотритесь в любой объект в реальном мире, опишите его наиболее подробно (материал, размер, цвет, вес, плотность, составные части и т.д.), это будут его свойства. Опишите, что и каким образом этот объект умеет делать (включаться, складываться, кушать электроэнергию, взаимодействовать с другими объектами или окружающей средой и т.д.), это будут его методы. Подумайте, для чего используется этот объект, что ему нужно изменить или добавить, чтобы использовать в других условиях или целях, и на основе всех собранных знаний создать более удобный экземпляр, это будет наследование и полиморфизм. Теперь немедленно забудьте обо всем, используйте объект по назначению, это будет инкапсуляция. Дальше останутся только тонкости выбранного Вами языка, шаблоны, методологии и прочаяие ересь тренды.

Вообще не проблема авторизоваться из разных таблиц
Делаете для админки новую страницу входа
В config/auth добавляете нового Охранника

'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],
        // новый
        'admin' => [
            'driver' => 'session',
            'provider' => 'admins',
        ],
    ],

Там же пропивывайте нового провайдера с доступом к нужной модели

'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => App\Models\User::class,
        ],

        // новый провайдер
        'admins' => [
            'driver' => 'eloquent',
            'model' => App\Models\Employee::class,
        ],
    ],

При авторизации использовать нового Охранника Auth::guard('admin')->attempt($credentials)

И все, у Вас в одной сессии могут существовать 2 пользователя в одном браузере

Минус такого подхода: Если админ захочет пользоваться сайтом как пользователь, то он должен зарегистрироваться как пользователь. Т.е. у него будет 2 учетки

Ну а дальше играйте ролями как хотите.

1) Заявки прикреплены к компании по id.

А в чем проблема? Если таблицы связаны через FK на уровне базы то все ок. Реляционные базы как раз для этого и делали.

2) Для всех заявок создана всего лишь одна таблица.
Мне кажется, что нужно делать отдельные таблицы для каждой компании. Как сделать правильно?

Зачем такое извращение? Какую проблему вы хотите решить, добавляя для каждой компании новую таблицу?
Если нет конкретной причины (при том - очень весомой), по которой нужно реализовывать подобное, используйте текущее решение, ибо как минимум встает вопрос: а как вы будете пилить запросы? Prepeared statments/pdo не позволяют подставлять названия таблиц. Без них - будет проблема с безопасностью. Чтобы ее решить нужно будет городить лишний код и т.д.

Убери точку с запятой в php.ini перед
extension=php_fileinfo.dll

Вариантов много. Достаточно часто я работал в режиме, когда фронт выдаёт мне рыбы, а я делаю из них шаблоны. Сталкивался с вариантом, когда фронт осилил язык шаблонизатора, благо он достаточно примитивный. И совсем частый в наше время вариант - отказаться от шаблонизатора. Бэкенд делается просто rest-сервисом, от которого фронтенд получает данные и рендерит страницы своими силами.

1) Как мне запустить этот файл через обычную html кнопку?

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

Поэтому изначально проектируется таким образом, что контроллер быстро передает управление стороннему компоненту все параметры пользователя и другие, необходимые для обработки, а сам возвращает ответ 200 или 202.
Сторонний компонент предоставляет из себя диспетчер очереди задач. В "упаковку"-задачу кладут все аргументы, "запаковывают" и помечают в БД, что создана задача X во время T и она в статусе ожидания.
Обработчиков очереди задач (отдельный от веб-приложения процесс) может быть как несколько, так и достаточно большое количество. Каждый такой обработчик помечает в той же БД, что задача X находится в обработке и приступает к парсингу с полученными аргументами. По окончанию помечает что выполнено, а результаты парсинга сохраняет в БД.

Как отображать какую-то информацию на странице (не результат парсинга, а промежуточную, например, код ответа с отправленных запросов) , которая приходит из parse.py

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

Как например остановить процесс парсинга

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