MVV

CancellationToken, передаваемый коструктору Task, не имеет никакого отношения к делегату, составляющему тело задачи (у вас им является ваша лямбда-функция). Он служит для отмены самой задачи, пока она ещё не запущена на выполнение. А делегат тела задачи даже не может просто взять и обратиться к этому CancellationToken. И, чтобы делегат мог с ним работать, этот CancellationToken надо передать делегату каким-то другим образом.
Вы передаете этот CancellationToken через замыкание лямбда-функции (это умное слово означает, что вы просто сослались в ней на эту переменную). Причем, вы его передаете в тело и той, и другой задачи, через одну и ту же переменную token. Именно поэтому при вызове Cancel() для источника этого CancellationToken (cancelTokenSource) обе задачи обнаруживают этот факт и прекращают свое выполнение.
PS Если интересует, где про это прочитать побольше, то - в книге Дж.Рихтера "Программирование на платформе Microsoft .NET Framework 4.5 на языке Csharp, CLR via Csharp" в гл.27 (в более новом издании, если такое есть, номер главы может измениться).

Если вы, как у вас написано, передаете название страны и города через путь в 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 
 }
}

Поток повторно запустить нельзя. После th1.join() (этот вызов дожидается завершения потока) cоздайте новый поток, присвойте его нужной переменой - да хоть той же th1 - и запустите его: будет функциональный аналог Task.ContinueWith(). Или же запустите th2, который у вас уже создан, но не запущен.
Если вы хотите сделать два вызова Print в одном потоке - сделайте. Если между первым и вторым вызовом надо выполнить какой-нибудь код в основном потоке, то придется использовать объекты синхронизации, в данном случае - события, и ждать на них. Про это курите тему ManualResetEvent/AutoResetEvent, в двух словах в ответе всю эту тему не объяснить

//...declarations and initializations omitted
           do
           {
               //...some code omitted
               if (j != i)
               {
                   swap(i, j);
                   i = j; 
               }
           } while (j != i);

Не работает, потому что вы сначала присваете j значение i, если они не равны, а потом, в условии продолжения цикла, сравниваете их значения. Естественно, они будут равны и выход их цикла получится на первой же итерации. Проверять i==j как условие выхода из цикла надо чуть раньше, например, так:

//...declarations and initializations omitted
           do
           {
               //...some code omitted
               if (j != i)
               {
                   swap(i, j);
                   i = j; 
               }
               else break;
           } while (true);

Ну, а что до второго вопроса, то в .NET, начиная с 6.0 есть класс System.Collections.Generic.PriorityQueue<TElement,...

Естественно не можете, потому что ServiceResult у вас IEnumerable не реализует (про это написано в сообщении об ошибке). А IEnumerable, по которому можно пройтись - это параметр-тип для ServiceResult, и до значения этого типа еще надо добраться.
Разберитесь, что это у вас за обобщенный тип - ServiceResult (похоже, это из какой-то сторонней библиотеки), найдите в нем свойство типа T (или метод, возвращающий T) - который тип T в вашем случае - это IEnumerable - и пройдитесь циклом foreach по значению этого свойства (или результату, возвращенному методом).
PS Если не найдете - дайте больше информации по используемым библиотекам (пакетам NuGet и т.п.), иначе придется вам ждать телепатов или ясновидящих, чтобы они эту информацию нам передали.

Во-первых, ваш заголовок вводит в заплуждение: в нем - про завершение процесса, а справшиваете вы про завешение задачи.
Во-вторых, задача может завершаться переходом в разные конечные состояния (они фиксируются в поле Task.Status). По оператору Return задача переходит в состояние RanToCompletion, по ThrowIfCancelationRequested - Canceled. Это - два логически разных состояния завершения (есть еще и третье - завершение по необработанному исключению, Faulted). Если коду, создаывшему задачу, совсем без разницы, как именно завершилась задача и вообще, завершилась ли она, то можете делать как угодно.
Но, очень часто код, связанной с задачей,к примеру, операция await для задачи, ведет себя по-разному, в зависимости от состояния завершения задачи, получение результата задачи - тоже. А для задачи продолжения можно задать условия, при каком состоянии завершения предыдущей задачи эта задача продолжения будет запущена. То есть, состояние завершения задачи обычно имеет значение.

В .NET есть стандартный класс System.Uri
Посмотрите, может вам хватит его возможностей?

Вынесите описания переменных наверх, над swicth.

int PlayerDamage ;
int PlayerHealth;
int PlayerResist ;

 switch(characterChoose)
 {
     case 0:
         PlayerDamage = 50;
         PlayerHealth = 150;
         PlayerResist = 25;
         break;
     case 1:
         PlayerDamage = 75;
         PlayerHealth = 125;
         PlayerResist = 15;
         break;

 }

PS Согласен с предыдущим комментатором - инциализация через оператор switch выглядит тяжеловесно. В нынешнем C# можно записать то же самое сильно короче, через деконструкцию, например.
PPS Держите пример с вашеми данными, как это должно выгдядеть стильно-модно-молодежно:

int characterChoose = Convert.ToInt32(Console.ReadLine());
(int PlayerDamage, int PlayerHealth , int PlayerResist)=characterChoose switch
{
    0 => (50, 150, 25),
    1 => (75, 125, 15),
   //... дописать все остальные варианты
} ;

Браузеру надо сообщить, что настройки изменились парой вызовов процедуры InternetSetOption из WinInet.dll. Вызывать надо через P/Invoke На stackoverflow нашел пример, как это делать в Powershell.

function Refresh-System
{
  $signature = @'
[DllImport("wininet.dll", SetLastError = true, CharSet=CharSet.Auto)]
public static extern bool InternetSetOption(IntPtr hInternet, int dwOption, IntPtr lpBuffer, int dwBufferLength);
'@

$INTERNET_OPTION_SETTINGS_CHANGED   = 39
$INTERNET_OPTION_REFRESH            = 37
$type = Add-Type -MemberDefinition $signature -Name wininet -Namespace pinvoke -PassThru
$a = $type::InternetSetOption(0, $INTERNET_OPTION_SETTINGS_CHANGED, 0, 0)
$b = $type::InternetSetOption(0, $INTERNET_OPTION_REFRESH, 0, 0)
return $a -and $b
}

Адаптируйте этот код к C# (пояснение: Add-Type в PS служит для загрузки сборки или неуправляемой DLL ). Или поищите по имени этой процедуры код на C#.

Используйте LINQ:
Если поле code в типе, получаемом после десериализации имеет тип int (по уму должно быть так, но я с NewtonSoft JSON не работал, поэтому не уверен в таких подробностях), просто допишите к выражению для десериализации
.Select(x=>x.code).ToArray();
Если тип, паче чаяния, другой - преобразуйте результат, возвращаемый лямбда-функцией в Select к int (для строки это будет Int32.Parse(x.code)

Думаю, что надо раскрыть подробнее тему предыдущих ответов и комментариев.
Проблемы со сложностью у вас, потому что вы не используете современые средства .NET и C#.
В .NET исторически сложилось несколько слоев API для обеспечения параллельной работы, и использование функций обратного выдова - самый старый и самый громздкий из них. А самый удобный и современный - это Task Parallel Library (TPL): он, плюс конструкции языка C# async/await, позволяет писать такой асинхронно выполняющийся код так, будто он выполняется синхронно.
Скорее всего (я просто не уточнял, потому пишу так) для SQLite есть асинхронный API и для использования с TPL, и API для синхронного использования, что ещё удобнее - и он должен быть не менее быстрым чем синхронная работа с файлами, потому что это встроенная БД.
Но если вы по каким-то причинам будете работать с асинхронным API на функциях обратного вызова, то тут тоже есть способ упростить код: транслировать вызовы такого API для использования его со средствами TPL. Для этого используйте объект типа TaskCompletionSource (в вашем случае - обобщенный, специалиированный вашим типом результата: TaskCompletionSource<int>
У этого объекта есть свойство Task, возвращающее задачу, состоянием котрой можно управлять с помощью методов этого объекта - SetResult и других, вызывая эти методы в функциях обратного вызова (AKA callback). Как это делать - см. пример по ссылке.
А с Task, каким бы способом вы его не получили, вам будет работать значительно удобнее: если пометить метод, в котором вам надо работать с БД как async (в современном C# так можно пометить даже Program.Main), то в этом методе можно будет использовать для получения значения операцию await

TaskCompletionSource<int> tcs1=new TaskCompletionSource();
//... операции по по настройке tcs1 и запуску первого чтения из БД
int numberFromBase1 = await tcs1.Task.ConfigureAwait(false);
TaskCompletionSource<int> tcs2=new TaskCompletionSource();
//... операции по по настройке tcs2 и запуску второго чтения из БД
int numberFromBase2 = await tcs2.Task.ConfigureAwait(false);
int summ =  numberFromBase1 + numberFromBase2;
return summ;

Вызов ConfigureAwait(false) здесь нужен для избежания блокировок в некоторых контекстах синхронизации (приложения Windows Forms, WPF и др.). Если же у вас программа выполняется вне специфического контекста синхронизации - консольное приложение, приложение ASP.NET Core и др., - то этот вызов не обязателен.
Компилятор, увидев операцию await, преобразует метод нужным образом, так, чтобы он выполнялся асинхронно, передавая управление другим задачам во время ожидания (т.е. до выполнения функции обратного вызова) и возобнавлял выполнение по его завершении -и вам думать об этом и писать нужный для этого код будет не нужно.
Такой метод вернет Task (возможно - ещё до завершения всех операций) и с его результатом можно что-то сделать: либо получить его опять чере await асинхронно, либо дождаться завершения асинхронных операций с получением результата через вызов метода Task<int&gt.GetAwaiter().GetResult() (есть другие варианты, но этот IMHO лучше всего в плане обработки исключений).

Мое мнение: есть некоторая неопределенность для ответа. С одной стороны, при решении типовых задач с помощью базирующихся на ASP.NET Core фреймворках высокого уровня - MVC, Razor, Minimal API, Blazor (за последний не совсем уверен, правда), с асинхронностью и многопоточностью вы сталкиваться будете не сильно и не часто, потому что в них приложены усилия, чтобы изолировать разработчика от связанных с этим трудностей - короче, потребуется разве что, умение использовать async/await. Но в целом ASP.NET Core - это фреймворк асинхронный и многопоточный, поэтому для более плотной работы с ним понимание асинхронность и многопоточность и связанные с ней знания (например, про примитивы синхронизации, состояние гонок и т.п.) может быть полезно, иногда - например, если вы захотите использовать объекты, к которым возможен доступ из нескольких веб-запросов параллельно - просто необходимо.
Короче, мое мнение: начинать изучать перечисленные фреймворки высокого уровня можно и без особых знаний про асинхронность, достаточно научиться использовать await в async-методах (это просто). Но в дальнейшем тему асинхронности и многопоточности надо вкурить, чтобы можно было работать смелее и свободнее, выходя за рамки фрейворка, и не допускать при этом труднообнаружимых ошибок.

если я не хочу создавать переменную

А вы её и так, и так не создаете: экземпляр исключения создается при возбуждении исключения (помните синтаксис - throw new Exception() )? А вот чтобы обратиться к полям/свойствам/методам этого экземпляра, надо дать ему имя в конструкции catch и обращаться к нему по этому имени. А при указании в качестве имени экземпляра имени класса, вы, как выше вам написал Василий Банников , как и в любом другом месте, обращаетесь к статическому полю (или свойству) этого класса. Такой вот синтаксис у языка C#: обработчик исключения у него - это обычный блок, никаких специальных соглашений там нет( пока что, по крайне мере ;-) ).

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

Если надо один раз: правой кнопкой мыши на нужный проект -> Debug -> Start New Instance
Если надо изменить на постоянку: правой кнопкой мыши на нужный проект -> Configure Startup Project...
или Меню->Project->Startup Project...
Предполагается, что все эти проекты входят в одно Решение (Solution)