hzzzzl

Нужно запретить все символы, кроме символов из белого списка типа a-zA-Z0-9_
Проверка должна быть на сервере. На клиенте проверка нужна, только чтобы не перегружать страницу лишний раз.

Вашему фронтендщику стоит посоветовать сначала изучить как это делается а потом огород городить.
но судя по тому что вы вместо него это выясняете, его все устраивает а вас - нет.

Так конечно никто не делает, есть понятия аутентификации и авторизации, сессия устанавливается после аутентификации (пользователь подтверждает что он - это он) и потом этот пользователь авторизуется с каким-то правами и в сессию каким-нибудь подходящим образом ставятся атрибуты авторизации, в простейшем случае - роль пользователя (админ/юзер). Эти атрибуты фронт может запросить у бэка отдельным запросом или получить в ответе на /login.

Не очень понятно что значит "запрос для входа пользователя" и "запрос для входа менеджера" -
у вас предполагается что пользователь будет нажимать на разные кнопки "войти как менеджер" и "войти как пользователь" или что?

Нормально так:
Кнопка для логина - одна.
запрос аутентификации - один.
сервер отвечает ошибкой или успешным ответом. Сама сессия ставится кукой, эта кука по хорошему должна быть httpOnly и из js кода не доступна. С ней работает исключительно бэкенд и так как хочет.
Аппа из ответа сервера (в body) либо сделав отдельный запрос (типа /currentUser) понимает что это за пользователь - менеджер или обычный и сохраняет это куда-то себе. В случае реакта это с большой вероятностью стор. Можно в localStorage чтобы при перезагрузке читать сразу оттуда.

Дальше аппа просто смотрит в стор в нужные моменты чтобы понять что пользователю показывать что нет.
Все права на запросы бекенд разруливает на основе сессионной куки которая приходит с каждым запросом автоматически. То есть сессии как таковой фронт вообще никак не касается - его дело - вызывать login/logout, получить от бэка инфу о текущем юзере и правильно обрабатывать 401.

Можно сделать и более сложные варианты - без куки, с каким-нибудь токенами и прочим, но скорее всего вашему фронтэндщику еще рано.

Никак. Даже если взять фреймворк, то и там где-то внутри будет тупо цикл.

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

.disable-all-buttons button {
  pointer-events: none; /* отключаем реакцию на клик и тап */
  opacity: 0.6; /* делаем кнопку "бледной" */
}

Кидаем этот класс на общий контейнер и bob's your uncle.

Вечер добрый.
Вы не тупой, в ангуляре существует модуль роутинга.
Да, ангуляр сам получает событие изменения адресной строки, и, согласно вашему коду, на него реагирует.
Ответы:

1. Да, сервер, в случае SPA просто отдает данные из БД а если роут ему неизвестен - просто отдаст index.html, в котором будет бандл angular (или React) приложения, которое развернется и проверит, что написано в адресной строке, может ли это приложение обработать этот запрос. Все таки изначально, при первом запросе url идет до бэкэнда.
2. Ну, если вы не хотите использовать Angular - да, такой подход имеет место быть, вопрос только зачем - современные фреймверки позволяют без боли создавать приложения. не нравится ангуляр - пробуйте React или Vue.
3. Да, ангуляр, как и реакт - для SPA. Не отвечу точно про ВК, судя по всему да, или использует много элементов оттуда.
4. Да, дает, ваш бэкэнд в данном случае (в случае православного простого SPA) превращается в обертку для БД (очень условно, тапками не кидайте, всякое бывает, я знаю).