Василий Банников

2. Не избыточна ли тут ConcurrentQueue?

Вместо неё лучше использовать System.Threading.Channels (https://www.stevejgordon.co.uk/an-introduction-to-...)

3. Как сообщить основному потоку из Task.run() что все готово к обновлению карт? Я понимаю что есть Task.Result, но если Task выполняется постоянно (while true), смогу ли я это использовать?

При помощи канала.
А Task.Result испольщовать не следует

В остальном всё звучит правдоподобно

Нет, такое не происходит, тк размер объектов просто не может меняться в процессе работы.
Объект либо сразу большой, либо сразу не большой

Single File Application - фича современных дотнетов со времён .net Core 3
Буквально при помощи одной опции в файле проекта или одной строкой в консоли собирает ваш проект в единый екзешник, в который ещё может быть опционально встроен рантайм.
Вот пример csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <PropertyGroup>
    <!-- Вот это самое главное -->
    <PublishSingleFile>true</PublishSingleFile>
    <!-- Это чтобы тащить за собой рантайм До .NET 6 будут рядом лежать нативные библиотеки jit-а и сборщика мусора-->
    <SelfContained>true</SelfContained>
    <!-- Это необходимо, чтобы сборщик понимал, для какой ОС нужен экзешник -->
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <!-- Это чтобы ускорить запуск -->
    <PublishReadyToRun>true</PublishReadyToRun>
    <!-- Эти две строки, чтобы уменьшить размер бинарника -->
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>link</TrimMode>
  </PropertyGroup>
</Project>

В результате получается единственный exe, который реально можно запустить где угодно, вне зависимости от установленной версии .NET

Для старых версий дотнета есть ILMerge и Costura.Fody, но в .net 5+ они не нужны, и я крайне советую использовать именно .NET 8, тк он сейчас самый актуальный

Ну во-первых точно не получится использовать стандартный Bitmap.
Хранить в куче такой большой объект тоже не следует, тк он 100% попадёт в LOH
+ в .NET есть ограничение в 2гб на объекты в управляемой куче.
Описанное вами изображение как раз в этот лимит и не влезет.

Остаётся два с половиной варианта:
1. Делить огромное изображение на чанки по меньше (либо по пикселям, либо по каналам, либо и так и так)
2. Хранить изображение в неуправляемой памяти, выделять и освобождать память вручную.
В .net 6 как раз добавили Native alloc API для этого.
3. Возможно есть какая-нибудь нативная библиотека для работы с большими изображениями.
Возможно даже уже есть обёртка для работы с ней.

Во всех случаях придётся отказаться от Bitmap и использовать другие подходы

без доп. библиотек и массива битмапов

Не получится

То этот самый хост, запустится в отдельном фоновом-процессе? То есть, процесс консольного приложения отдельно, а процесс-хоста - отдельно?

Нет. Он будет запущен в этом же процессе.

PS: не забывайте писать await возле вызовов асинхронных методов

Xamarin.Native не заменит
Xamarin.Forms заменит (тк это но и есть)
WPF не заменит (но это не точно)

Ну и не надо смотреть только на майков - есть и другие кроссплатформенные UI - например Avalonia или Uno

1. Небольшая экономия, за счёт того что не нужно длинный запрос по сети передавать, а только короткий вызов процедуры (относительно)
2. В плане защищённости разницы нет, если злоумышленник имеет доступ к исполняемому файлу/исходнику.
3. Из потенциальных удобств - можно менять запрос, не затрагивая приложение.

Так что выбирай тот способ, который в твоём случае более оправдан.

tl;dr; Чтобы дать интерфейс для явного освобождение какого-нибудь ресурса, как правило - неуправляемого.
Цитата из документации

В основном этот интерфейс используется для высвобождения неуправляемых ресурсов. Сборщик мусора автоматически освобождает память, выделенную управляемому объекту, если этот объект больше не используется. Однако невозможно предсказать, когда произойдет сборка мусора. Более того, сборщик мусора не имеет сведений о неуправляемых ресурсах, таких как дескрипторы окон, или открытых файлах и потоках.
Используйте Dispose метод этого интерфейса для явного освобождения неуправляемых ресурсов в сочетании с сборщиком мусора. Потребитель объекта может вызвать этот метод, если объект больше не нужен.

Есть ли смысл изучать его ради маленьких в пару страниц сайтов (но всё же серверным функционалом, не просто "отдать html по ссылке")?

Для продакшена - да. HttpListener даже на линуксе вроде не будет работать, тк зависит от http.sys

Какие у него есть киллер-фичи, облегчающие жизнь?

1. Быстрый
2. Гибкий
По сравнению с httplistener.

я слегка пересрался от вида "пустого проекта asp net" в visual studio.

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

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

Host.CreateDefaultBuilder(args)
    .ConfigureWebHost(webBuilder =>
    {
        webBuilder.UseKestrel(o =>
        {
            o.ListenLocalhost(5000);
        });
        webBuilder.ConfigureServices(services =>
        {
            services.AddRouting();
        });
        webBuilder.Configure(app =>
        {
            app.UseRouting();
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapGet("/", async context =>
                {
                    await context.Response.WriteAsync("Hello World!");
                });
            });
        });
    })
    .Build()
    .Run();

В .NET 6 будет MinApi, который выглядит вот так (без юзингов):

var app = WebApplication.Create(args);

app.MapGet("/", string () => "Hello World!");

app.Run();

И к великому разочарованию не обнаружил там своего дотнета

Опрос за 2020 год:
https://insights.stackoverflow.com/survey/2020#mos...
Судя по нему - ASP NET Core - самый любимый фреймворк среди веб-разработчиков
Но при этом старый ASP NET - один из самых нелюбимых.