MVV

Судя по вашему сегодняшнему вопросу, в котором вы пытаетесь решать эту задачу дальне вам нужно сделать эту работу на уровне БД.
Если так, то для этого многие (хоть и не все, но, к примеру, в MS SQL Server и в PostgreSQL она AFAIK есть) СУБД имеют функциональность reursive CTE.
Попробуйте поискать решение в этом направлении.

Полагаю, вы хотели подставить между знаками процента значение из поля ввода (txtSearch.Text), которое передается в string.Format? В таком случае надо между фигурным скобками подставить порядковый номер параметра (он начинается с 0): string.Format("%{0}%", txtSearch.Text)

PS Из соображений безопасности (чтобы избежать SQL-инъекции) крайне не рекомендуется напрямую копировать в строку запроса сырые, непроверенные, данные из ввода пользователя - а вы сделали именно так. В учебной задаче это допустимо, но лучше сразу привыкать делать по уму: например, использовать в строке запроса параметры и передавать ввод через них.

Имя_файла.cs ищется относительно вашего текущего каталога - того, в котором вы находились, когда ввели команду с csc.exe. Его имя пишется в приглашении командной строки. Вот и посмотрите, из какого каталога вы запускаете команду, и есть ли там нужный файл.

CityzenUNDEAD, сообщение об ошибке означает, что у вас таки действительно кривые данные, а именно - есть минимум одна запись в RiskLevels со значением поля OrganizationControlId = 0, для которой в таблице OrganizationControl нет записи с таким же значением первичного ключа (как я понял - поля Id).
Вывести все такие записи из RiskLevels, которые ссылаются на отутствующие записи в OrganizationControl, можно SQL-запросом

SELECT * FROM RiskLevels WHERE OrganizationControlId!=ALL(SELECT Id FROM OrganizationControl)

И пока такие записи есть, наложить ограничение внешнего ключа не поле RiskLevels.OrganizationControlId у вас не получится. Ищите и разбирайтесь, что с этими записями делать.

PS Entity Framework - он шибко умный, он сам находит связанные друг с другом поля, сам добавляет поля для чего-нибудь типа первичного ключа и т.д. Так что не удивляйтесь, что EF умничает, а если не хотите этого - жестко его контролируйте.

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

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-пакеты, но подробности я вам тут не опишу.
А в общем совет у меня такой: собирайте информацию и думайте сами, а попытки копировать "как у других" - они могут привести к совершенно неожиданным результатам: каждая задача в чем-то уникальна.

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