Александр

Сериализация. В xml/json/бинарно.

не в БД

А чего? sqlite же.

Что в WebAPI, что в MVC все те же контроллеры. Разница только в том, что в методах возвращается или json, или вьюха. Ищите примеры тут

Models

Модели вам по-любому понадобятся, как ViewModels чтоб строить JSON (вы же не собираетесь json руками генерить?), так и какая-то бизнес-логика.

я вижу сильную привязку к контроллерам из чего рождается вывод, что для работы по таким проектам требуется fullstack подход,

В идеале, у вас бизнес-логика (вся) должна быть отдельно. Контроллеры -- только мост между бизнес-моделями и выводом (вьюхи это, json - не важно).

Может быть тогда все же CIL компилируется в код для операционной системы, которая уже занимается окончательным его переводом в машинный код для процессора?

Нет такого понятия код для операционной системы. Операционная система -- точно такая же программа (в реальности -- комплекс программ), как и все остальные.

если CIL действительно компилируется в машинный код, который уходит непосредственно процессору на исполнение, то зачем указывать список целевых операционных систем?

CIL транслируется в машинный код рантаймом (например, моно) в момент непосредственно перед исполнением. И если рантайм не умеет работать на определенной ос, то и CIL там не заработает.
Т.о., при проектировании программы Вам необходимо знать, на каких ОС есть рабочий рантайм. Также, если Вы обращаетесь к сервисам ОС (неявно, через обертки .net, предоставляемые BCL, или явно -- через DllImport), Вам нужно знать, на какой ОС будет выполняться Ваше приложение, дабы учитывать возможности ОС.

https://docs.microsoft.com/ru-ru/dotnet/core/
https://docs.microsoft.com/ru-ru/dotnet/core/linux...

https://github.com/TelegramBots/Telegram.Bot
Даже ничего писать не буду, берете и пользуетесь. Без всяких asp

Нет exe, да. dotnet appname.dll
Или вот
И вообще официальный мануал

Или вы используете конструкцию using, или уничтожаете объект сами.

https://docs.microsoft.com/ru-ru/dotnet/core/linux...
Просите у хостера любой х64 дистрибутив из списка и вперед.

1) Мне кажется что в каждом запросе к API проверять валидность IP - Token (запрос к БД) будет долго и ответы будут больше пол секунды, как можно решить или так и делают?

Кеш in-memory для активных токенов.

2) Везде где читаю про эту тему пишут: "Не пишите сами, будет куча дыр! Используйте готовые решения. (Owin и тд)"
Есть ли в моей модели дыры?

На стадии модели дыры рано искать, да и модель у вас поверхностная. Как будут генериться токены, какой сложности, вероятность коллизий - вот это вот все решает.

3) Если я сделаю сайт (Веб приложение) который будет обращаться к API (я так понимаю как и обычный клиент - HTTP запросами), то по идее мой сайт будет одним из пользователей который использует Token и держит его в Header, будет ли виден он в веб-отладчике? с какого IP будут уходить запросы, сервера или пользователя? Я имею ввиду те корые будут не в контроллерах сайта, а Ajax.

Смотря какой апи и как вы реализуете. Ajax - это клиентская технология, да, токен будет виден в отладчике.

Вот как раз от UserName не избавиться. IdentityUser является реализацией интерфейса IUser. Можете взять исходники Identity и изменить интерфейс IUser.

А можно и попытаться перекрыть UserName емейлом и исключить из модели бд. Тогда, по идее, UserName никак участвовать не будет, но на практике не проверял.

public class MyUser:IdentityUser
{ 
       [AlwaysValid] //Всегда валидно
        [NotMapped] //не маппим в EFCore
        public string UserName
            {
                get => Email;
                set => Email = value;
            }
}
        public class AlwaysValid : ValidationAttribute
{
                public override bool IsValid(object value) => true;
                   
}