MVV

Вы неправильно используете метод ControllerBase.Forbid. Передаваемая в него строка (она, как понимаю, преобразуется в массив строк из одного элемента) - это не сообщение об ошибке, а название использованного метода аутентификации.

Для ответа на вопрос несколько не хватает информации - как у вас организована реакция на отмену IHostApplicationLifetime.ApplicationStoping (что и как делает регистрируемый callback при отмене), какие сервисы вы используете и как они реагируют на отмену того же маркера.
И IMHO информацию лучше собирать методом проб и ошибок. Самое первое, что вы можете попробовать - это такой вариант. Во-первых, нужно зарегистрировать свой callback последним. А для этого нужно вызвать конструкторы всех сервисов в надежде, чо если они и регистрируют callback на этот маркер, то делают это у себя в конструкторах и только потом регистрировать свой callback (если вы эти сервисы получаете путем внедрения зависимостей через конструктор, это получится автоматически). Во-вторых, нужно выполнить всю работу в своем callback синхронно, в частности, если сообщения отправляются сервисами асинхронно, то подождать завершение каждого (Tasl.WaitAll вам в помощь), а не ждать каждый через await (или явно - используя ContinueWith - но сейчас так никто не делает).
Идея рассчитана на то, что реализация IHostApplicationLifeTime отменяет (ЕМНИПпроверено в исходниках) этот маркер простым Cancel и ждет завершения отмены (и в документации об этом ожидании смутно упомянуто, т.е., это не хак, зависящий от реализации) , а Cancel вызывает все зарегистрированные callback синхронно, в порядке, обратном регистрации (это ЕМНИП тоже документированнное поведение).
Попробуйте для начала так, прежде чем применять более крутые меры (например, подменять реализации IHostLifeTime и IHostApplicationLifetime(UPD: погорячился, эту реализацию подменять нельзя, там обязан быть класс ApplicationLifetime) - технически это реально, но лучше такое оставить на потом).
Если не прокатит, я ответ постараюсь продолжить.

PS По поводу способов закрытия приложения. AFAIK остановка через "красный квадратик" в VS и закрытие окна консоли вызывает просто уничтожение процесса, и это не перехватывается (могу ошибаться, конечно). А вот закрытие по Ctrl+C отлично перехватывается ConsoleLifeTime (обычно испольуемая для консольных приложений реализация IHostLifetime), так что именно этот способ закрытия можно считать штатным. А вообще по жизни, 100% срабатывающих способов реакции на прекращение работы приложения нет - ибо прекращение может быть вызвано такой причной, как пропадание питания (особенно - если вследствие перерубания кабелей топором ;-) ).

У вас в поле _helper класса FormHelper<TModel> конструктор сохраняет ссылку на интерфейс IHtmlHelper<TModel>.
Этот интерфейс содержит свойство ViewData типа ViewDataDictionary<TModel>. А в этом типе реализовано свойство Model (типа TModel), которое даст вам ссылку на экземпляр класса (типа TModel) модели для представления/страницы.
Ну, а дальше, раз вы знаете имя нужного вам свойства объекта и имеете ссылку на экземпляр этого объекта, то можете получить значение этого свойства: либо через составление с последующей компиляцией и вычисление выражения, возвращающего его значение, либо через отражение.
Как-то так.

В ASP.NET Core есть стандартный механизм сеансов (ISession): https://learn.microsoft.com/aspnet/core/fundamenta...
Работает он на базе распределенного кэша (IDistributedCache), который штатными средствами можно базировать на MS SQL и на Redis (и, возможно, есть дополнительные сторонние пакеты для базирования на других СУБД,). Идентифкатор сессии хранится в куки (настраеваемой), по умолчанию - HTTP-only (но это настраивается).
Механизм устаревания сеансов там есть, параметры тоже можно настроить.
Кароче, если нет причин обязательно делать свой велосипед (типа, для учебной задачи) можно использовать этот стандартный механизм.
Правда идея использовать этот механизм именно для авторизации у меня вызывает некоторые неясные опасения: он, вообще-то, не для того сделан. А именно для авторизации (плюс аутентифкация) в ASP.NET Core тоже есть штатное решение (Identity и политики авторизации). И вообще, аутентифкация/авторизация - это такое место, где легко накосячить, а потому лучше там обходиться без своих велосипедов.

Исправьте вот здесь:

[Column("profilePicturePath")]
    public string? ProfilePicturePath { get; set; }

Пояснение. В документации по EF Core написано:

Если включены ссылочные типы, допускающие значение NULL, свойства будут настроены на основе nullability C# для типа .NET: string? будут настроены как необязательные, но string будут настроены по мере необходимости.

В современных шаблонах проектов nullability включена по умолчанию, так что ваш тип свойства string EF понимает как то, что соответствующая колонка записи должна иметь ограничение NOT NULL. А потому вам следует использовать в качестве типа свойства string? .

Идея генерировать содержимое HTML на основе внешних данных - она правильная. И шаблоны Razor (.cshtml) предоставляют для этого очень удобные средства, кстати. Так что хранить данные в самих шаблонах - это неправильная идея (вы в этом уже убедились, да).
По поводу вашего предложения, как зранить данные, у меня есть совет: экспортируйте эти файлы из Excel в формат техта с разделителями (например, CSV, а я лично предпочитаю в качестве разделителей знаки табуляции). Это - обычные тектовые файлы, которые можно, при необходимости, править и без Excel (хоть в Блокноте), а для больших правок - импортировать в Excel. И всякие средства для контроля версий, типа Git - они с текстовыми файлами работают значительно лучше, чем с файлами excel.

PS Как вам правильно написал в комментарии Sergey В. , для хранения данных лучше использоваь базу данных. Вы особенно это оцените, если функциональность проекта будет расширяться. А внешние файлы - хоть Excel, хоть текстовые - это эрзац-решение. Но если для вас это терпимо, а использовать БД в проекте вам сложно, то используйте файлы.

Параметры маршрута привязываются к параметрам метода обработчика страницы по имени, т.е. их имена в директиве @page в шаблоне страницы и в списке параметров метода в коде должны совпадать.
А у вас в @page используется id, а в списке параметров OnGet - pageId. Переименуйте что-нибудь, чтобы имена одинаковые были - и будет вам счастье.

Не легче ли внедрение делать через конструкторы?

А вы не задумывались над тем, кто и как будет разрешать зависимости для конструкторов?
В нынешнем ASP.NET Core этим занимются каркасы приложений ("фрейворки", от английского framework). И делают они это как раз через контейнер сервисов (либо напрямую через GetService, либо через ActvatorUtilities).
Но есть области в ASP.NET Core , которые фремворками не закрываются - наример, в конвейере обработчиков запроса (middleware), там где требуется делегат типа RequestDelegate. И там без прямого обращения к контейнеру сервисов не обойтись.

Если вы, как у вас написано, передаете название страны и города через путь в URL, то параметры метода Action для URL второго формата должен привязываться к переменной маршрутизации, примерно так:

[HttpGet("{country}/{city}")]
public IActionResult ActionMethod([FromRoute] String country, [FromRoute] String city) 
{
  //... method code
}

[FromRoute] можно и не писать, если параметров запроса (то, что после '?' в URL) нет: привязка по умолчанию выберет следующим источником переменные маршрутизации.
PS Можно обойтись одним методом действия (Action), если указать что city - параметр необязательный

[HttpGet("{country}/{city?}")]
public IActionResult ActionMethod([FromRoute] String country, [FromRoute] String? city) 
{
 if(city==null) {
  //... method 1 code 
 }
 else {
  //... method 2 code 
 }
}

'MultipleActiveResults=True'

Уберите эти одинарные кавычки.