MVV

Если у вас установка свежая и ещё не в бою, считаю предпочтительным вариант выше, от Роман Безруков .
Но есть альтернатива, которую можно попробовать: загрузиться в безопасном режиме восстановления службы каталогов (надеюсь пароль для этого режима у вас есть) и переименовать компьютер обратно, как было. После чего - помолиться своему богу или постучать по дереву и попробовать перезагрузиться.
PS

Не то, чтобы ответ, но идея ответа. И если чо непонятно - могу в каментах поуточнять.
Со стороны тыла (на C#) можно ограничить число параллельных запросов в целом к сервису безо всяких там плагинов, а саморучно сделанным велосипедом: семафором (например, SemaphoreSlim, как самым модным в этом сезоне). Либо сделать его статическим, либо (чтобы веру в IoC свято блюсти и модульные тесты делать) - запихнув в Singleton-сервис с теми же свойствами/методами, что и у семафора используются, и получать этот сервис через конструктор (передавать через DI - в бою, напрямую - в тесте).
Для семафора(сервиса) устанавливаете максимальное число параллельно выполняемых запросов в качестве начального значения. При входе в обработчик захватываете семафор (Wait/WaitAsync, таймаут - по вкусу), при выходе (лучше - в блоке finally того try, который начинается после захвата семафора) - освобождаете (Release).
Таймаут выставляете в зависимости от поведения фронта: какие у него у самого таймауты на запрос (в том числе - на повторение) и как он реагирует на задержку ответа и на всякие разные коды статуса HTTP в ответе. В целом, стратегии тут две. Первая - пытаться захватывать семафор с коротким таймаутом и в случае неудачи - возвращать другой код статуса, кроме ОК, чтобы сказать фронту, что он не прав. Вторая - тормозить лишние запросы таймаутами. Кароче, без знания вашего фронтового плагина тут точно не скажешь, а я его знать не знаю и знать не хочу.

Это вам Google Chrome пишет, что этот пароль утек (где-то, когда-то): Google Chrome стал шибко умным и любит теперь поучать пользователей, что они должны делать, а что - не должны. На эту тему нынче даже статья на Хабре есть.
Так что пароль, скорее всего, утек не у вас (ибо много кто из разработчиков пользуется сайтами в домене localhost ;-) ), но я бы, к примеру пароль сейчас поменял, чисто на всякий случай.
Если вам надоела опека Google Chrome, то ее можно(пока?) отключитью Конкретно как включить (а, следовательно отключить) - про это в Интернете ссылок много, например, такая). Только потом, если чо, не жалуйтесь.

PS Использовать самопальную аутентифкацию/авторизацию крайне не рекомендуется (если вы не Брюс Шнайдер, конечно, или кто-нибудь вроде него). Потому что в этом деле тонкостей много и накосячить можно влегкую. Совет тут простой: посмотреть, как в вашем стеке стандартным образом реализуется аутентифкация с авторизацией (про .NET - см. документацию, а ещё, если непонятно, есть куча учебников)и сделать именно так, стандартно. В частности, передавать каждый раз на сервер логин с паролем плохо из соображений даже не безопасности, а производительности: аутентификация (полноценнная) - довольно дорогая операция. Сейчас для этого стали модны token, раньше обходились cookie. Но выбор, как всегда - за вами.

Во времена оны были программы-"соксификаторы", которые перехватывали трафик, идущий через socket API (т.е. - практически любой TCP/UDP) и заворачивали на socks-прокси. Я судьбой тех программ давно не интересовался, но беглый поиск дал мне наводку на то, что такой функциональностью из современных обладает некая ProxiFire (статья про нее на Хабре).
Личные рекомендации дать не могу: используйте на свой страх и риск. Или ищите альтернативы, ключивое слово для поиска - "socksify": именно так называлось в упомянутые времена заворачивание трафика сокетов на SOCKS proxi на уровне системных библиотек или ниже.

Идея, которая вам пришла в голову, известна давно, ее общепринятое название: "сегментная адресация памяти"
Про такую схему адресации и ее использование в ОС для защиты памяти я, к примеру, читал в книге по ОС ранних 80-х годов.
Во времена 16-битных микропроцессоров семейства x86 (8086-80286) и 16-битного ПО для них сегментная адресация памяти примнялась очень широко, сначала - потому что одного 16-битного адреса для адреса не хватало для адресации типичного объема памяти ПК, затем - и для разграничения доступа к памяти ОС и разных задач. Самое, наверное, известное ПО, использовавшее сегментную адресацию - это семейство Windows 3.x.
С появлением микропроцессоров этого семейства с 32-битной адресацией (80386 и далее), сегментная адресация была почти вытеснена линейной (т.к. разрядности адреса стало хватать для адресации всей памяти). Почти - но не совсем: в частности инфраструтура структурной обработки исключений (SEH) Windows NT использовала, а нынешних версий Windows, как ее потомков, и сейчас использует сегментный регистр FS. В частности, поэтому аппаратная поддержка этого регистра сохранилась в каком-то виде и в архитектуре x86-64, которая в целом от сегментной адресации отказалась.

1. Сразу насчет микросервисов: оно, конечно, стильно-модно-модожежно, но для начала ознакомьтесь со свежим переводом недавней статьи на Хабре "Смерть от тысячи микросервисов" и задумайтесь: а у вас там точно требуется такой уровень гибкости, масштабирования и т.п., что без микросервисов никак. Задуматься стоит IMHO - выбор неоднозначный, и за вас его никто не сделает.
2. Если вы знакомы с MVC и кго контроллерами, то вам будет несложно писать контролеры API на ASP.NET Core в старом добром стиле: традиционно они тоже базируются на инфраструктуре MVC. Там почти та же логика привязки параметров: ну, разве что, там стало автоматическим преобразование объектов на JSON из тела запроса в параметр-объект, но, вроде бы, можно использовать и старый стиль с несколькими параметрами с привязкой их одноименным свойствам объекта. Там используется та же самая маршрутизация по атрибутам - она должна быть вам знакома, если только вы не застряли в legacy времен MVC Framework 4, где была только центральная маршрутизация. Ну а возвращаемые объекты ASP.NET Core сам автоматически преобразует в JSON.
Правда, начиная с ASP.NET 6 появился (а начиная с ASP.NET 7 стал нормально документированым) альтернативный вариант создания API - Minimal API, но раз у вас есть опыт работы с MVC, то наверное, вам лучше остаться с этим старым добрым вариантом.
Насчет формата обмена - вызовов и результатов API - у вас полная свобода, но имейте в виду, что при использовании REST вы получите автоматизированню поддержку описания этих форматов через OpenAPI/Swagger: фронтовики с мобильщиками это оценят.
Делать ли генерацию HTML для браузера на веб-сервере через View по шаблонам Razor или же поручить эту работу фронтовикам, снабжая их данными через API - это предмет выбора, это зависит: как там у вас с квалификацией фронтовых разработчиков, как с требованиями к интерактивности страницы в браузере (MVC этому не способствует, костыли для подключения фронтовых фреймворков у MS, вроде как, есть, но я за них ничего не скажу - не пользовался), не придется ли по соображениям производительности переходить к Server Side Rendering (View - они как раз про это, а если изначально HTML генирился на фронте то перенести его в ASP.NET будет сложно) и т.п.
Авторизацация в ASP.NET Core есть из коробки, самых разных видов: часть уже встроена, для части придется подключать сторонние NuGet-пакеты, но подробности я вам тут не опишу.
А в общем совет у меня такой: собирайте информацию и думайте сами, а попытки копировать "как у других" - они могут привести к совершенно неожиданным результатам: каждая задача в чем-то уникальна.

1. Элемент с нужным id ищется через document.getElementById(id)
2. Затем внутри этого элемента ищите элемент с нужным классом (через querySelector, к примеру, есть и другие варианты) и кликаете на него.
Короче, если безо всяких проверок, как-то так:

document.getElementById('send-present-friend-593199183122')
   .querySelector('.async-gift-sending_send-button.friend-card_send-present-button')
   .click();

Работа фонового сервиса у вас прекращается потому что у его метод ExecuteAsync дожидается инициализации статической переменной WebView (она содержит ChromiumWebBrowser, открытый на странице https://web.watsapp.com) а потом ничего не ждет, а просто завершается. А что там у вас происходит с браузером, код вашего фонового сервиса не контролирует.
PS Я не вижу ваш остальной код, но могу предположить, что вам для работы программы этот фоновый сервис не нужен, т.к. вся работа с экземпляром CefSharp идет через упомянутую статическую переменную.

Помимо разрешений на папку:
1. Убедитесь, что папка и файлы внутри нее не открыты по сети (в узле "Общие папки\Открытые файлы"в консоли управления компьютером, например).
2. Убедитесь, что у вас есть разрешения на удаление всех подпапкох и файлов на все подпапки внутри этой папки (имейте в виду, что наследуемые разрешения могут и не примениться, т.к. разрешения хранятся для кажого файла или папки отдельно).

Чтобы понять причину, смотрите в Wireshark, что за IP адрес содержится в пересланном пакете DHCPDISCOVER в поле "Relay agent IP Address" (giaddr, если нужно название по спецификации, находится прямо перед MAC клиента). Чтобы все работало, этот адрес должен попадать в одну из областей (scope), определенных на сервере по адресу/маске обласьт - тогда адрес клиенту будет предложен (DHCPOFFER) из этой области.
Вот и смотрите, что за адрес приходит, есть ли у вас область с адресом/маской, под которые этот адрес попадает, активирована ли эта область и т.д.
О результате пишите в комментарии.

Скорее всего, у вас что-то не так с разрешением имен в IP. Проверяйте (ping в помощь)